· updated

【未経験OK】AIエージェント 作り方｜業務で使う4ルート実例

AIエージェントを作ってみたいけれど、Python＋LangChain ／ ノーコード（Dify・n8n・Make・Zapier）／ Microsoft Copilot Studio ／ Claude Projects・ChatGPT GPTs と道筋が多すぎて、どこから手を付ければいいか分からないと感じていませんか。実際、ラッコキーワードの実測（2026 年 5 月時点）でも「AIエージェント 作り方」は月 4,400 人以上が検索しており、私自身も業務でこの 4 ルートすべてを使い分けてエージェントを構築しています。

結論から言うと、まずは自分のスキル感に合うルートを 1 つだけ選び、最小サンプル（1 回の API 呼び出し、または 1 つの GPTs）から動かすのが筋です。本記事では、4 ルートそれぞれの最小サンプル、LLM の選び方、思い通りに動かないときの対処、コスト感、機密情報の取扱いまで、業務でこの 4 ルートを使い分けている現役の生成AIエンジニア視点で整理します。

AIエージェントとは何か（概念そのもの）は別記事 AIエージェントとは で扱っています。本記事は「概念は分かった、で、どう作る？」に応えるスポーク記事です。

01 — 結論：4 ルートのうち、自分に合う 1 つを選んで最小サンプルから動かす

📖 この章で使う用語

  • AIエージェント：目的を伝えると、自分で道具（Web 検索・電卓・メール送信など）を使って手順を組み立てて進めるアシスタント。営業の「目的だけ伝えれば段取りを組む新人」のイメージ。
  • LLM（Large Language Model：大規模言語モデル）：ChatGPT / Claude / Gemini の正体にあたる「文章を予測する装置」。
  • ルート：ここでは「AIエージェントを作る道筋」の意味で使います。4 ルート＋補足 1 ルートの計 5 ルートを後述します。

AIエージェントの作り方は、いきなり全部を比較するより、まず 1 ルートを選んで最小サンプルを動かすのが結局いちばん早い、というのが私の業務感覚です。私の場合、業務で 4 ルートすべてを使い分けていますが、それぞれを並行で立ち上げたのではなく、1 ルートずつ「これで何が作れるか」を手元で確かめてから次に進んできました。

迷ったときの選び方を 4 行で書くと、こうなります。コードを書きたくない・今日中に何か動かしたいなら、ルート D（Claude Projects または ChatGPT カスタム GPTs）。ノーコードで業務フローに組み込みたいなら、ルート B（Dify / n8n / Make / Zapier 等のいずれか）。社内の Microsoft 365 環境に組織エージェントを乗せたいなら、ルート C（Microsoft Copilot Studio）。Python でゴリゴリ書きたい・本格的に内製したいなら、ルート A（Python + LangChain/LangGraph + 直 API）。

ここで温度感を先にお伝えしておきます。本記事のルート A〜D は、すべて私が業務で常用している範囲です。一次体験として書きます。一方、補足で扱うローカル LLM（Ollama / Llama / Mistral など）は、私の業務では本番運用していません。手元の個人検証レベルで触った範囲＋公開情報からの概論までに留めます。SERP 上位の記事は「1〜2 ルートに偏った構成」か「理論解説のみ」のどちらかが多いので、本記事は 「4 ルートを業務で実際に使っているもので俯瞰し、補足 1 ルートは実体験ベースか公開情報ベースかを分けて書く」 という構造で差別化します。

「初心者だから無理では」「個人だから無理では」「無料で試したい」という気持ちは、Google サジェストでも上位に並ぶ典型的な不安です。結論から言うと、完全にコード未経験ならルート D を $20/月で、API を触ってみたいならルート A の最小サンプルを無料クレジット内で、SaaS 連携が好きならルート B の Free プランで、それぞれ無料〜数千円で「最初の一歩」を踏めます。詳しくは LLM とは と RAG とは の周辺記事も合わせて読むと、AIエージェントの「土台」が掴めます。

なお、本記事では「絶対これがいい」「必ず動く」のような言い切りはしません。エージェント開発は読者の前提（コード経験・社内環境・扱うデータ）で最適解が変わるため、最終判断はあなた自身の状況に当てはめて行っていただくのが現実的です。

02 — AIエージェントとは（30 秒の前提整理）

📖 この章で使う用語

  • メモリ（記憶）：直前の会話や過去の経緯を覚えておく仕組み。営業の議事録メモのような役割。
  • ツール（道具）：エージェントが外の世界とやり取りする道具。電卓・地図アプリ・メーラーなど、エージェントが「使える道具」として渡されるものをまとめてこう呼びます。
  • チャットボット：問いに答える「質問返答型」のアプリ。AIエージェントとは「目的→道具→手順」の自律性で区別します。
  • 検索拡張生成（RAG）：外部の文書を検索して、その結果を踏まえて答えを生成する仕組み。詳細は RAG とは で扱っています。

AIエージェントとは、ひとことで言うと 「目的を伝えると、自分で道具を使って手順を組み立てて進めるアシスタント」 です。営業の現場で例えると、「来週の出張、A 社訪問のアポを 2 件取って、移動経路と昼食候補も決めて」と新人に伝えたとき、自分で電話をかけ、地図を見て、お店を予約して結果を返してくれる——あの動きをソフトウェアにしたものです。

部品としては大きく 3 つです。LLM（判断する頭脳）、メモリ（記憶）、ツール（外の世界に触れる道具）。この 3 部品の組み合わせが「エージェント」です。本記事はこの「3 部品を、どう組み立てるか」の実装ルートを 4 つ（＋補足 1 つ）に整理した形になっています。

チャットボット・RAG・AIエージェントの違いを 1 表に整理しておきます。

種別仕組み何ができるか例
チャットボットLLM に質問を投げて答えを返す質問返答カスタマーサポート Bot
RAGLLM＋外部文書検索社内文書を踏まえた回答社内ナレッジ Bot
AIエージェントLLM＋メモリ＋ツール＋自律実行目的→道具→手順を自律実行自動リサーチ・自動オペレーション

詳細な概念解説は AIエージェントとは に整理しています。本記事は概念から作り方への橋渡しなので、ここでは「3 部品の自律実行」だけ押さえて先に進みます。

03 — 作り方の全体像：4 ルート俯瞰 + 補足 1 ルート

📖 この章で使う用語

  • LangChain（ラングチェイン）：Python / TypeScript で LLM アプリを組むためのフレームワーク。「定型作業の道具箱」のイメージ。
  • LangGraph（ランググラフ）：LangChain の上で、エージェントの状態遷移を図のように組む拡張ライブラリ。
  • ノーコード：プログラミングを書かずに、画面上の操作で組み立てる方式。Excel の関数を少し凝った GUI で組むイメージ。
  • API（エーピーアイ）：プログラム同士がやり取りするための「注文票」。
  • AWS Bedrock：Amazon Web Services が提供する LLM 統合サービス。Claude / Llama 等を AWS の契約・課金体系で利用できます。
  • GUI（グラフィカルユーザーインターフェース）：ボタンやアイコンを画面で操作する方式。コードを打たない方式の総称。

AIエージェントの作り方は、大きく 4 ルート＋補足 1 ルート に整理できます。SERP 上位の競合は「ノーコード○選」「LangChain チュートリアル」「Copilot Studio の使い方単独」のどれかに偏った構成が多いのですが、私の業務感覚では、実際にはこの 4 ルートを使い分けるのが現実的です。理由は単純で、目的（個人で試す／業務に組み込む／組織展開する）によって最適なルートが違うからです。

ここで改めて温度感を明示しておきます。ルート A〜D は、4 つすべて私が業務で常用している領域です。業務で実際に使っているものとして書きます。補足ルートのローカル LLM だけは、私の業務では本番運用していません。第 14 本目「AI 画像生成 無料」や第 18 本目「AI 議事録 おすすめ」と同型の温度感分離宣言として、補足ルートの章の冒頭で改めてお伝えします。

ルート向く読者主な道具学習コスト月コスト目安私の温度感
A. Python + LangChain / LangGraphエンジニア／コードを学んでいる方Python、Anthropic / OpenAI / Google SDK、AWS Bedrock中（1-3 ヶ月）API 数百円〜数千円業務で常用（一次体験から書ける）
B. ノーコード（Dify / n8n / Make / Zapier 等のいずれか）非エンジニア／PoC を早く回したい方ブラウザの GUI低（1-2 週間）Free〜数千円業務で常用（一次体験から書ける）
C. Microsoft Copilot Studio社内 IT 部門／全社展開担当Microsoft 365 連携、GUI 中心中（1-2 ヶ月）M365 ライセンス連動業務で常用（一次体験から書ける）
D. Claude Projects / ChatGPT GPTsコードを書かない簡易構築をしたい方Claude.ai / ChatGPT 上の機能極低（30 分〜半日）Pro プラン $20/月〜業務で常用（一次体験から書ける）
補. ローカル LLM（Ollama / Llama / Mistral 等）機密データ／オフライン／コスト最適化自分の PC or 社内サーバ高（GPU 環境構築）ハード次第個人検証レベル（公開情報からの概論として紹介する扱い）

Google サジェスト 10 件のうち、「python」「ノーコード」「copilot」「claude」「chatgpt」「gemini」「ローカル」の 7 件は、この俯瞰表の各ルート（と次章以降の LLM 選び）にそのまま対応します。残りの「個人」「初心者」「無料」3 件は セクション 10「個人開発者の最初の壁と乗り越え方」でまとめて吸収する構成にしました。

なお、エディタ環境としては Claude Code 使い方 や Cursor 使い方 を併用すると、特にルート A（Python）の学習が加速します。

04 — ルート A：Python + LangChain / LangGraph で作る（最小サンプル）

📖 この章で使う用語

  • SDK（エスディーケー：Software Development Kit）：各社が公式に提供している「自社サービスを呼ぶための公式ライブラリ」。Anthropic SDK、OpenAI SDK、Google AI SDK などがあります。
  • venv / uv：Python のプロジェクトごとに依存ライブラリを分ける道具。「プロジェクト専用の道具箱」をプロジェクト単位で作るイメージ。
  • pip：Python のライブラリをインストールするコマンド。pip install anthropic のように使います。
  • ループ：エージェントが「考える→道具を使う→結果を見る→次を考える」を繰り返す処理の流れ。

ルート A は Python でコードを書いて、LLM の API を直接叩く道です。私の業務でのメインスタックはこのルートで、本格的な業務エージェントの内製はほとんどここから入ります。最小サンプルは 20〜50 行で動きます。

ルート A には大きく 2 パターンあります。(1) 公式 SDK を直接叩いて、エージェントのループも自前で書くパターンと、(2) LangChain / LangGraph などのフレームワーク経由で書くパターンです。私の業務では(1)をメインスタックにしつつ、(2)も部分的に使っています。どちらが正解という話ではなく、目的次第です。

4-1. パターン(1)：公式 SDK 直叩き + 自前ループ

まず最小サンプルから。Anthropic Claude を例にした 1 ツール（電卓）エージェントです。

# anthropic_agent_min.py
# 公式 SDK 直叩き + 自前ループの最小サンプル（30 行強）
import os
import anthropic

client = anthropic.Anthropic(api_key=os.environ["ANTHROPIC_API_KEY"])

# エージェントに渡す「道具」の定義（電卓 1 つ）
tools = [{
    "name": "calculator",
    "description": "数式を受け取って計算結果を返す電卓",
    "input_schema": {
        "type": "object",
        "properties": {"expression": {"type": "string"}},
        "required": ["expression"],
    },
}]

def use_tool(name: str, args: dict) -> str:
    # 道具の中身（本番はここに業務ロジックを入れる）
    if name == "calculator":
        return str(eval(args["expression"]))
    return "未対応の道具です"

# エージェントのループ：考える → 道具を使う → 結果を渡す → 続きを考える
messages = [{"role": "user", "content": "123 * 456 + 789 を計算して"}]
while True:
    resp = client.messages.create(
        model="claude-3-5-sonnet-latest",
        max_tokens=1024,
        tools=tools,
        messages=messages,
    )
    if resp.stop_reason == "end_turn":
        # 道具を使い終わって、最終回答が返ってきた
        print(resp.content[-1].text)
        break
    # 道具呼び出しが返ってきたら、結果を作ってループに戻す
    tool_use = next(b for b in resp.content if b.type == "tool_use")
    result = use_tool(tool_use.name, tool_use.input)
    messages.append({"role": "assistant", "content": resp.content})
    messages.append({"role": "user", "content": [{
        "type": "tool_result",
        "tool_use_id": tool_use.id,
        "content": result,
    }]})

動かす前提は Python 3.10 以上、pip install anthropic の 1 行と、Anthropic コンソールで取った API キーを環境変数 ANTHROPIC_API_KEY にセットすることだけです。

私がこの「公式 SDK 直叩き + 自前ループ」を業務メインに置いている理由は、大きく 3 つあります。(1) 依存が最小なのでデバッグが楽、(2) ループの中身が全部見えているので、想定外の動きが起きたときに追える、(3) 各社の API 仕様が変わっても、影響範囲が局所化される。本格的にプロダクトに乗せるとき、これは結構な安心感です。

API キーの取得方法は記事を分けています。Claude 側は Claude 使い方 、ChatGPT 側は ChatGPT 始め方——営業出身の現役生成AIエンジニアが、登録から非エンジニア活用まで整理しました を参照してください。

4-2. パターン(2)：LangChain / LangGraph 経由

同じ電卓エージェントを LangChain / LangGraph で書くと、定型部分（ループ・ツール呼び出しの繋ぎ込み）を省略できます。最小サンプルはこんなイメージです。

# langgraph_agent_min.py
# LangGraph 経由の最小サンプル（おおむね 20 行で動く）
from langchain_anthropic import ChatAnthropic
from langchain_core.tools import tool
from langgraph.prebuilt import create_react_agent

@tool
def calculator(expression: str) -> str:
    """数式を受け取って計算結果を返す電卓"""
    return str(eval(expression))

llm = ChatAnthropic(model="claude-3-5-sonnet-latest")
agent = create_react_agent(llm, tools=[calculator])

result = agent.invoke({
    "messages": [("user", "123 * 456 + 789 を計算して")]
})
print(result["messages"][-1].content)

pip install langchain langchain-anthropic langgraph の 1 行で入ります。コード量は大幅に減りますが、その代わり LangChain / LangGraph の概念（Runnable・StateGraph・Node など）を覚える学習コストが乗ります。

私が業務で LangChain / LangGraph を選ぶときの判断軸は、次の 3 つです。(1) 複雑なワークフローを組む必要がある（並列実行・条件分岐・人手の介入ステップなど）、(2) 複数の LLM を切り替えながら使いたい（Anthropic と OpenAI で同じインターフェースで書ける利点）、(3) 既存の LangChain 資産がチーム内にすでにある。逆に言うと、これらに当てはまらないシンプルなエージェントは、公式 SDK 直叩きで書くほうが結局シンプルです。

なお、AWS Bedrock 経由で Claude を呼ぶ選択肢もあります。私の業務でも一部使っており、選ぶときの判断材料は (1) AWS の IAM（権限管理）と統一できる、(2) VPC 内通信で社外にデータを出さない構成が組める、(3) AWS の課金体系に統合できる——あたりです。直 API（Anthropic API 直叩き）との違いは概念整理レベルでお伝えできますが、業務本番運用の細部や具体的な料金最適化テクニックは、私の業務でも限定的な範囲でしか触れていませんので、深掘りは控えます。

「無料で試したい」という方への即答：Anthropic / OpenAI ともに、新規アカウントには無料クレジットが付与される運用です（金額・条件は時期で変動するため、各社公式ページで最新を確認してください）。最小サンプル 1 回の実行コストは、現行価格帯ではおおむね数円〜十数円程度の感覚です。

RAG エージェント（社内文書を踏まえて答えるエージェント）への発展は、別記事 RAG とは に基礎をまとめています。

05 — ルート B：ノーコードで作る（Dify / n8n / Make / Zapier 等）

📖 この章で使う用語

  • Dify（ディファイ）：OSS（オープンソース）の LLM アプリ構築プラットフォーム。チャットボットやエージェントを GUI で組めます。Cloud 版と Self-Hosted 版があります。
  • n8n（エヌエイトエヌ）：OSS のワークフロー自動化ツール。Zapier の OSS 版に近い位置づけで、AI ノードから LLM を呼べます。
  • Zapier / Make：SaaS（クラウドサービス）同士を画面の操作で繋ぐ自動化サービス。Make は旧 Integromat。
  • PoC（Proof of Concept：概念実証）：本格導入の前に「使い物になるか」を試す段階。
  • OSS（オープンソースソフトウェア）：ソースコードが公開され、誰でも使える形で配布されているソフトウェア。

ルート B は ノーコード AI エージェント構築プラットフォームで作る道です。私の業務でも、これらのツール群のいずれかを常用しています。「コードは書けない／書きたくない」「PoC を早く回したい」「業務フローに組み込みたい」という目的にハマる道です。

代表的なツールは Dify / n8n / Make / Zapier の 4 系統に整理できます。私の業務常用は このうちのいずれか ですが、各ツール群の位置づけを 1 段落ずつ整理しておきます。具体的にどれを業務で使っているかという個別ツール名の特定は、案件の都合もあるので本記事では伏せます。

Dify は LLM アプリ構築 OSS の代表格です。チャットボット・エージェント・ワークフローを GUI で組めて、プロンプト設計・ナレッジ管理（RAG 機能内蔵）・公開 API 化までを 1 ツールで完結できます。Cloud 版は無料プランから始められ、Self-Hosted 版は自社サーバや社内 PC に立てて使えます。「PoC を早く回したい」「公開 API として呼びたい」という用途に向きます。

n8n は OSS のワークフロー自動化ツールです。Zapier に近い思想ですが、Self-Hosted で運用できるのが特徴です。AI ノードから OpenAI / Anthropic などの LLM を呼び出せて、社内システムへの接続（社内 DB・社内 API）も柔軟に書けます。「社内ワークフローを自前で持ちたい」「クラウド SaaS に依存したくない」場合に向きます。

Make（旧 Integromat）は SaaS 連携自動化サービスです。500 を超えるアプリ統合があり、AI モジュールから LLM を呼べます。視覚的なシナリオエディタが特徴で、複雑なワークフローも図で組めます。「複数の SaaS を跨いだ自動化が中心」の場合に向きます。

Zapier は最古参の SaaS 連携サービスです。Zapier AI Actions で LLM 統合があり、Free プランから試せます。「既存の SaaS スタックがすでに Zapier 中心」「とにかく簡単に始めたい」という方に向きます。

私の業務での選定軸をこれまでの経験で整理すると、こうなります。PoC を早く回す目的 なら Dify（LLM アプリ構築に特化していて立ち上がりが早い）。社内ワークフローを内製で持ちたい なら n8n（Self-Hosted で社内データに繋ぎやすい）。既存 SaaS スタックが大量にある なら Zapier または Make（連携アプリの数が圧倒的）。どれが「一番いい」という話ではなく、目的に合うものを選ぶのが結局いちばん早い、というのが私の感覚です。

非エンジニアの方が最初の一歩を踏むなら、Dify Cloud の Free プランがいちばん入りやすい型です。流れはこんなイメージです。

  1. Dify Cloud にアカウント登録（無料）
  2. 「新しいアプリ」→「チャットボット」を選ぶ
  3. プロンプト（指示文）を 1 つ書く：例「ブログ記事の構成案を 3 つ提案してください」
  4. LLM プロバイダー（OpenAI / Anthropic / Google など）を選ぶ
  5. テストチャットで動かす → 公開リンクを発行

ここまでで 30 分 あれば、自分専用の AIエージェント を 1 つ公開できます。最初は「これだけ？」と肩透かしを食うかもしれませんが、業務エージェントもこの延長線上にあります。

失敗パターン（業務で実際に使っているもの） も 3 つ挙げておきます。

  • (1) LLM の応答品質はプロンプト次第：ノーコードでも、プロンプトが雑だと結果も雑です。プロンプトを 5〜10 回練り直す前提で取りかかるとラクです。
  • (2) ツール接続の認証は意外と詰まる：API キーの取得、OAuth 認可、IP 制限など、業務システムに繋ぐとここで時間を取られがちです。
  • (3) ノーコードでも本番運用には監視・エラー処理の設計が必要：「動いた」と「本番に乗せられる」は別物です。エラー時の通知・リトライ・ログ保管をどう組むかは、ノーコードでも設計の対象になります。

業務効率化の文脈で他のツール群と組み合わせる視点は、別記事 AI 業務効率化 ツール に整理しています。

06 — ルート C：Microsoft Copilot Studio で作る（組織向け）

📖 この章で使う用語

  • Microsoft Copilot Studio：Microsoft 365 と連携する組織向け AI エージェント構築プラットフォーム。
  • GitHub Copilot：エディタ（VS Code 等）でコードを補完してくれる Microsoft の別製品。名前は似ているが Copilot Studio とは別物です。
  • Power Platform：Microsoft の業務アプリ構築群（Power Apps / Power Automate / Power BI / Copilot Studio）。
  • SharePoint：Microsoft の社内ポータル／文書管理サービス。
  • DLP（Data Loss Prevention：情報漏洩防止）：機密情報の流出を防ぐポリシー・仕組み。

ルート C は Microsoft Copilot Studio で組織向けエージェントを作る道です。私の業務でも常用しており、社内データに繋がるエージェント（社内文書参照型 Bot、Teams 連携、社内ナレッジ Q&A など）を組むときの主軸ルートのひとつになっています。

Google サジェスト 2 位の「copilot」は、Microsoft Copilot Studio の業務需要 と、GitHub Copilot との混乱 の両方を含んでいます。先に整理しておくと、この 2 つは完全に別製品です。

項目Microsoft Copilot StudioGitHub Copilot
用途組織向けエージェント構築エディタ内のコード補完
対象社内 IT 部門／全社展開担当個人開発者／開発チーム
環境Microsoft 365 / Power Platform 連携VS Code / JetBrains などのエディタ
料金体系M365 ライセンスや従量課金と連動個人 $10/月から
アウトプット業務エージェント・チャット Botコード補完・コード生成

GitHub Copilot は私も業務で使っており、エディタ環境の話は別記事の Claude Code 使い方 や Cursor 使い方 と合わせて読むと位置づけが見えてきます。本章では Microsoft Copilot Studio に絞って 整理します。

業務での使いどころ は、大きく 4 つあります。

  • (1) 社内データ参照型 Bot：SharePoint や社内ナレッジに繋いだ Q&A Bot。社員からの「あの規程どこ？」「あの手順は？」に自動で答える用途。
  • (2) Teams 連携エージェント：Microsoft Teams 上で動くチャット Bot として配信。「社員が日常的に使う場所」に置けるのが強み。
  • (3) Power Platform との接続：Power Automate のフローを呼び出して、業務システムを自動操作する。承認フロー・データ更新・通知などを Bot 経由で起こせます。
  • (4) 部門単位のエージェント配布：人事部用・経理部用・営業部用など、部門の業務に最適化したエージェントを配布する型。

個人開発者の方も、Microsoft 365 Personal や Family のサブスクリプションがあれば、Power Platform 系の機能の一部に触れられる時期があります。ただし、Copilot Studio の本領は テナント単位での組織展開 にあるので、個人で完結させるよりは「会社で導入する立場」になったときに本格的に活きるツール、と捉えるのが現実的です。

失敗パターン（業務で実際に使っているもの） も 2 つ挙げておきます。

  • (1) Microsoft 365 のテナント権限がないと検証しにくい：個人で気軽に試したい場合、Trial ライセンスを取らないと触りにくい場面があります。
  • (2) Power Platform 全体の学習コストは無視できない：Copilot Studio 単体ではなく、Power Automate との連携・DLP ポリシーの設定・テナント管理者承認など、Power Platform 全体の知識が後から効いてきます。

組織展開の文脈では、契約と権限の設計が後から効いてきます。社内 IT 部門と連携して進めることをおすすめします。

07 — ルート D：Claude Projects / ChatGPT カスタム GPTs（コードを書かない簡易エージェント）

📖 この章で使う用語

  • Claude Projects：Claude.ai 上で「専用知識を持った AI 相談相手」を作れる機能。PDF アップロード・カスタム指示・チームメンバーとの共有が可能です。
  • カスタム GPTs：ChatGPT 上で同じ思想の機能。API 接続・Web 検索・コードインタプリタ統合が標準で組み込まれています。
  • コードインタプリタ：ChatGPT 内で Python コードを実行できる機能。データ分析や計算で重宝します。
  • Claude Cowork：Claude Desktop 上でローカルファイル操作を任せる別系統のツール。Projects とは別物です（詳細は Claude Cowork 使い方）。

ルート D は コードを書かずに、Claude.ai や ChatGPT 上の機能で簡易エージェントを作る道です。「Python はまだ学習中」「Dify もまだ早い」「Copilot Studio はテナントがない」という方への即答ルートで、私の業務でも Claude Projects と ChatGPT カスタム GPTs を両方とも常用 しています。

Claude Projects（Claude.ai の機能） は、「専用知識と専用指示を仕込んだ AI 相談相手」を作れる機能です。PDF・テキスト・コードなどをアップロードしておくと、それを前提に答えてくれるようになります。カスタム指示で「あなたは○○の専門家として答えてください」「出力は箇条書きで」など、振る舞いを固定できます。チームメンバーと共有することも可能です。

私の業務での Claude Projects のユースケースを、抽象化して 3 つ挙げると：

  • (1) 社内ドキュメント要約用 Project：頻繁に参照する社内資料をまとめて入れておき、「○○の章を 3 行で」と聞くと整形して返す
  • (2) 議事録整形用 Project：「決定事項 / アクション / 課題」の出力テンプレートを仕込み、議事録メモを貼ると整形済みで返ってくる
  • (3) コードレビュー観点 Project：プロジェクトのコーディング規約・レビュー観点を仕込み、差分を貼って「指摘候補を出して」と頼む

ChatGPT カスタム GPTs も同じ思想ですが、Web 検索・コードインタプリタ・API 接続（GPT Actions）が標準で組み込まれているのが強みです。私の業務では、チーム内で配布する特定タスク特化 GPTs（例：「日報整形 GPTs」「リサーチ補助 GPTs」など）を作って配ることで、属人化を抑えながら AI 活用を広げる使い方をしています。

Projects と GPTs の使い分け は、こんな感覚です。

  • 精度重視（長文整形・複雑指示） なら Claude Projects（長文処理と指示遵守の安定感が私の業務感覚では高い）
  • Web 検索・コード実行が必要 なら ChatGPT GPTs（コードインタプリタと Web 検索が標準で組み込まれている）
  • 共有先のツール環境で選ぶ：チームが ChatGPT Plus 中心なら GPTs、Claude Pro/Team 中心なら Projects

なお、Claude Cowork（Claude Desktop 上でローカルファイルを操作する別系統のツール）と Claude Projects は、よく混同されますが別物です。Cowork は手元の PC のファイル・フォルダを Claude に直接触らせる用途、Projects は Claude.ai 上で「専用知識を持った相談相手」を作る用途、という棲み分けです。詳細は Claude Cowork 使い方 と Claude 料金プラン を参照してください。

「個人」「初心者」「無料」というサジェスト 3 件に対する、ルート D の即答はこうです。Pro プラン $20/月 で、コードを 1 行も書かずに 30 分で 1 個の Projects / GPTs を作れます。「個人で」「初心者から」「最初の出費を抑えて」始めるなら、現実的な選択肢です。

業務エージェントへの発展経路 としても、ルート D は有効です。私の業務では、いきなり Python で内製するのではなく、まず Projects / GPTs で「何を任せたいか」「どんな指示で動くか」を固めてから、必要に応じて Dify や Python に移行する型を採ることが多いです。要件定義の段階で動くプロトタイプを作れるのは、ルート D の大きな強みです。

ただし、Projects / GPTs を 「業務エージェント本番」と混同しない ことには注意が必要です。機密データの取り扱いポリシー・SLA・監視の観点で、本格エージェントとは別物として位置づけるのが現実的です。商用利用条件やデータ取り扱いについては、後段の セクション 13「法律・規約・セキュリティの注意」で詳しく整理します。

08 — 補足ルート：ローカルで動かす選択肢（Ollama + Llama / OSS LLM）

📖 この章で使う用語

  • Ollama（オラマ）：手元 PC で OSS LLM を動かす最も簡単なツール。brew install ollama 1 行で入ります。
  • Llama / Mistral / Qwen：OSS の LLM 代表 3 系統。それぞれ Meta、Mistral AI、Alibaba が公開しているモデル。
  • vLLM：本番運用向けの OSS LLM 推論サーバ。大量リクエストを捌くために設計されています。
  • GPU メモリ：画像処理装置（GPU）に搭載されているメモリ。LLM をローカルで動かすときに「載るか／載らないか」を決める要素。

ここから先のローカル LLM は、温度感を先にお伝えします。私の業務では本番運用していません。手元の個人検証レベルで触った範囲＋公開情報からの概論に留めます。業務常用のルート A〜D とは温度感が違う、という前提で読んでいただければと思います（第 14 本目「AI 画像生成 無料」の温度感分離宣言と同型のスタンスです）。

ローカル LLM とは、OpenAI / Anthropic / Google などの API を使わず、自分の PC や社内サーバで OSS LLM（Llama 3 系 / Mistral / Qwen 等）を動かす選択肢です。主な動機は次の 4 つです。

  • (1) 機密データを外部に出したくない：API 経由で社外にデータを送ることに制約がある業務領域
  • (2) クラウド非依存：外部サービスの障害・規約変更・価格改定に影響されない構成にしたい
  • (3) コスト最適化：高頻度・大量推論で、API 従量課金より自前サーバのほうが安く付くケース
  • (4) 検証用途：API キーの取得や課金登録なしに、まず動かしてみたい段階

主なツールは大きく 3 系統です。Ollama は手元 PC で最も簡単に OSS LLM を動かせるツールで、macOS なら以下の 1 行で入ります。

# Ollama を入れて Llama 3 を動かす最小コマンド
brew install ollama
ollama run llama3

LM Studio は GUI でモデルを管理・実行できるツール、vLLM は本番運用向けの推論サーバ、という棲み分けです。

私が個人検証レベルで Ollama を触った範囲での感想を、限定的にお伝えします（業務本番運用の話ではない点に注意してください）。(1) インストール自体は 1 行で入って、最初の起動はあっけないほど簡単、(2) ただし、商用 API（Claude / ChatGPT / Gemini）と同じ精度・速度を期待すると違和感がある、(3) GPU メモリの要件は無視できない（大きなモデルほど多くの VRAM を要求する）——あたりが正直な感想です。

業務利用に乗せるには、精度・運用負荷・モデルライセンスの 3 つの壁が高く、私自身もまだ業務本番運用には至っていません。「ローカルでまず試してみたい」「機密データを扱う前提で構成を考えたい」段階の検証として、Ollama から触ってみる入り口は良いと思います。

落とし穴 として、次の 3 つは事前に押さえておくと安全です。

  • (1) 商用 API 級の精度は出にくい：用途を絞る（特定タスクに特化させる、RAG で文脈を厚く渡す）前提で考える
  • (2) GPU メモリ要件は無視できない：手元 PC のスペックで動かないモデルもある
  • (3) ライセンス条項の確認：Llama 3 の利用許諾、Mistral の Apache 2.0 など、モデルごとに利用条件が異なる

OSS LLM の系統別の整理は、別記事 LLM とは で扱っています。本格的にローカル運用を検討する段階では、そちらも合わせて読んでみてください。

09 — LLM の選び方：Claude / ChatGPT / Gemini をどう使い分けるか

📖 この章で使う用語

  • マルチモーダル：文章だけでなく、画像・音声・動画も扱える性質。Gemini の強みのひとつです。
  • エコシステム：周辺ツール群・関連ライブラリの厚さ。OpenAI 系は分厚い印象です。
  • トークン：LLM が文章を扱う単位。日本語は 1 文字 1〜2 トークン程度の感覚。料金は「入力トークン数 + 出力トークン数」の従量課金が基本です。
  • コンテキストウィンドウ：LLM が一度に扱える文章の長さ（トークン数）の上限。

Google サジェストの「claude」「chatgpt」「gemini」3 件は、「どの LLM を選べばいいか」 という分岐点を表しています。私の業務では 3 系統すべての API を利用していて、使い分けの感覚をお伝えします。

LLM提供元用途のイメージ
Anthropic Claude APIAnthropic業務エージェントの本命候補のひとつ
OpenAI ChatGPT API（GPT-4 系）OpenAI既存資産が OpenAI 系のチームと相性が良い
Google Gemini APIGoogle画像入力を扱う／Google 系業務との接続

「迷ったら何にすべき？」というご質問への答えは、「絶対これがいい」とは申し上げません。私の業務では、用途・コスト・既存スタックで使い分けています。具体的には：

  • エージェントのツール使用が複雑 → Claude API を試す
  • 既存コードが OpenAI SDK ベース → GPT-4 系を継続
  • 画像入力を含むタスク → Gemini を選ぶ
  • コスト最適化が最優先 → 各社の小型モデル（Claude Haiku / GPT-4o-mini / Gemini Flash 系）を比較

AWS Bedrock 経由で Claude を呼ぶ選定軸も、改めて整理しておきます。直 API（Anthropic API 直接）と比べた違いは大きく 3 つで、(1) AWS の IAM 連携が使える、(2) VPC 内通信でデータを社外に出さない構成にできる、(3) AWS の課金体系に統合できる——という点です。社内のクラウド標準が AWS で、機密データ要件がある業務領域では選定候補に上がります。ただし、業務本番運用の細部や具体的な料金最適化テクニックは私の業務でも限定的な範囲でしか触れていないため、本記事では概念整理レベルまでに留めます。

料金感は API 従量課金（入力トークン数 + 出力トークン数）が基本ですが、各社の公式料金ページは頻繁に更新されるので、必ず公式ページで最新を確認してください。本記事で具体的な金額を書くと、読者がこの記事を読むタイミングで古い数字に基づいて判断してしまう可能性があるため、相場感だけお伝えすると、エージェントの最小サンプル 1 回の実行コストは現行価格帯で数円〜十数円程度、本格運用に乗せると月数百〜数千円〜の範囲、という感覚です。

「絶対 Claude が一番」「必ず GPT-4 を選ぶべき」という言い方はしません。最終判断は、あなたの用途・コスト・既存スタックで決まる、というのが私の業務感覚です。

LLM 自体の輪郭は LLM とは で先に掴むと、本記事のモデル選びが楽になります。

Claude 周辺の使い方と料金プランは Claude 使い方 で、ChatGPT 周辺は ChatGPT 始め方 で、それぞれ未経験者向けに整理しました。

10 — 個人開発者の最初の壁と乗り越え方

📖 この章で使う用語

  • JSON Schema（ジェイソンスキーマ）：データ構造を機械が読める形で定義する規格。エージェントの道具定義（ツールの入力フォーマット）に必須です。
  • クレジット：API プロバイダーが新規アカウントに付与する無料の利用枠。
  • utf-8：日本語を扱うときの文字コードの定番。文字化けを防ぐ要素。
  • エラーハンドリング：プログラムが失敗したときの後処理（リトライ・通知・ログ記録など）。

Google サジェストの「個人」（1 位）・「初心者」（6 位）・「無料」（8 位）の 3 件は、「自分一人で、経験ゼロから、なるべくお金をかけずに始めたい」 という同じ気持ちのバリエーションだと私は読みました。本章でまとめて吸収します。

私自身、営業から SES に未経験で入った最初の半年は、コードを書くより前に 「調べ方を覚える」 だけで精一杯でした。技術ブログを読んでも分からない、エラーメッセージの意味も分からない、英語のドキュメントは目が滑る——あの感覚は、いまでもよく覚えています。エージェント開発に取りかかる方も、おそらく似た壁にぶつかります。順番に整理します。

10-1. 5 つの壁

(1) API キー取得・課金設定：Anthropic / OpenAI / Google のコンソールでクレカ登録するときの心理的抵抗が、最初の壁です。私の場合、「無料クレジット内の上限を明示的に設定してから登録する」 ことで、うっかり数万円課金されるリスクを潰してから取り組みました。利用枠制限の設定は、各社のダッシュボードから可能です。

(2) Python 環境構築：venv / poetry / uv の選択肢があります。私は最近は uv 推奨です。理由はシンプルで、軽くて速いから。最小構成は次の通りです。

# uv で Python プロジェクトを作る最小手順
brew install uv               # macOS の場合
uv init my-agent              # プロジェクトを作る
cd my-agent
uv add anthropic              # 必要なライブラリを足す
uv run python my_agent.py     # 実行

(3) プロンプト設計の難しさ：1 発で意図通りに動くことはほぼ無いです。5〜10 回の試行錯誤が前提 だと割り切ってから、私は気が楽になりました。「うまく動かない」のは設計が悪いというより、エージェント開発の標準工程です。

(4) ツール定義の JSON Schema：エージェントが道具を使うための定義で、最初は型の書き方で詰まります。"type": "string"、"required": [...] などの記法を、最初の 1 つを動かしながら覚えるのが結局いちばん早い、というのが私の感覚です。

(5) デバッグの難しさ：「なぜ意図と違う動き？」を追うのに時間がかかります。私の場合、エージェントの「考えた中身（reasoning）」「使った道具と引数」「返ってきた結果」を全部ログに残す習慣をつけてから、追いやすくなりました。

営業時代に 1 日約 60 件の訪問で覚えたのは、断られてからが本番 ということでした。エージェント開発も似ていて、1 発で動かないところから本番が始まる、という感覚で取り組むと気持ちがラクです（あくまで個人の感想ですが）。

10-2. 「無料」「初心者」「個人」向け、即実行プラン

最後に、ご自分のスタートラインに合わせた即実行プランを 3 つに整理します。

  • 完全コード未経験の方 → ルート D（Claude Projects または ChatGPT カスタム GPTs）を Pro $20/月 で。30 分で 1 個作って、まず動かす感覚を手に入れる
  • コードを触ったことがある方 → ルート A の最小 Python サンプル（本記事 4-1 のコード）を、無料クレジット内で動かしてみる
  • SaaS 連携が好きな方 → ルート B の Zapier Free または Dify Cloud Free で、自分の普段使う SaaS とエージェントを繋いでみる

私自身も未経験から SE に入った経路をたどってきたので、最初の一歩の重さはよく分かります。詳しい体験談は 未経験エンジニア転職 にまとめています。

11 — 非エンジニアでも使えるユースケース 5 本

📖 この章で使う用語

  • PR（プルリクエスト）：エンジニアが「このコード変更をレビューしてください」とチームに送る単位。
  • Cursor MCP（Model Context Protocol）：Cursor から外部リソース（GitHub / Slack / 社内 API 等）を扱う仕組み。私は業務でセットアップして常用しています。
  • OCR（Optical Character Recognition：光学文字認識）：画像（PDF 等）から文字を読み取る技術。
  • 仕訳エクスポート：会計データを、後段の会計ソフトに取り込める形式（CSV など）で書き出すこと。

機能系の記事として、非エンジニアの方が AIエージェント をどう使えるか を 5 職種で整理します。読者ペルソナ（営業・事務・個人事業主・副業ライター・エンジニア）に沿った具体例で、Before / After / 所要時間・コスト / 最初の壁の 4 要素で書きます。

ここで先にお伝えしておくと、これは 「これで誰でも稼げる」「絶対に生産性が 3 倍になる」 という話ではありません。業務・個人差・職種特性で結果は変わります。私の業務感覚で「現実的に組める」型として、参考にしていただければと思います。

11-1. 営業：日々の顧客リサーチ自動化エージェント

  • Before：訪問前の顧客リサーチに 3 時間／件（公式サイト、IR 資料、ニュース検索を 1 件ずつ手で）
  • After：URL リストと観点を渡すと、要約と「商談で触れるとよさそうな話題候補」を返してくれる。30 分／件に短縮の目安
  • 所要時間・コスト：Dify Cloud で半日、月 0〜1,000 円程度
  • 最初の壁：Web 検索結果の精度にばらつきがある。事実確認は人手で行う運用ルールが必要
  • 使うルート：B（ノーコード）、または D（Claude Projects に観点を仕込む）

私自身が営業時代にこれが使えていれば、と思う型です。営業 7 年で 1 日約 60 件の訪問をしていた身として、訪問前リサーチに使える時間はいつも足りませんでした。

11-2. 事務：請求書 PDF → 仕訳エクスポートエージェント

  • Before：請求書 PDF を 1 件ずつ開いて、勘定科目と金額を手入力に転記。1 件 1 時間
  • After：PDF を投げると、OCR で読み取って、決まったフォーマットの CSV で返ってくる。1 件 5 分の目安
  • 所要時間・コスト：Python で 1 週間、または n8n + AI ノードで 2 日。月数百円〜
  • 最初の壁：PDF パース（読み取り）の精度。レイアウトが崩れた請求書は人手確認が要る
  • 使うルート：A（Python）、または B（n8n の AI ノード経由）

事務職の方が組むには Python のハードルが高いので、最初は n8n + AI ノードでの組み立てが現実的だと思います。

11-3. 個人事業主：問い合わせメール 1 次返信エージェント

  • Before：問い合わせメールに即時返信したいが、本業中は対応できず夜にまとめて返信
  • After：「定型的な質問」には 1 次返信を自動で返し、要対応のものだけ通知。24 時間 365 日対応
  • 所要時間・コスト：ChatGPT カスタム GPTs + Zapier で 1 日、月 $20〜
  • 最初の壁：誤返信の責任設計（自動返信を発射する範囲をどこまで絞るか）。重要な問い合わせを自動返信で済ませてしまうリスク
  • 使うルート：D（GPTs）+ B（Zapier）の組み合わせ

個人事業主の方は、「対応漏れの心理的負担」を軽くするだけでも十分意味があります。完全自動化を目指すより、まず「1 次返信＋人手の最終判断」の二段構えから始めるのが現実的です。

11-4. 副業ライター：競合記事リサーチエージェント

  • Before：1 案件あたり、競合 10 記事を読み比べて切り口を整理するのに半日
  • After：URL 群と「読みたい観点」を渡すと、要約と切り口候補を返してくれる。1 時間／案件に短縮の目安
  • 所要時間・コスト：Claude Projects で半日、または Python で 3 日。月 $20〜
  • 最初の壁：著作権の境界線。要約は OK だが、表現の流用は NG。自分の言葉に咀嚼するプロセスは残す
  • 使うルート：D（Claude Projects）、または A（Python）

副業ライターの方は、私の業務でも自分でブログを書く立場として共感する型です。リサーチに時間を取られすぎると、執筆時間が削られて結果的にクオリティが下がる、というジレンマがあります。

11-5. エンジニア：PR レビュー支援エージェント

  • Before：1 PR を丁寧にレビューすると 1 時間。差分が大きい PR は半日
  • After：差分を読んで、コーディング規約違反・潜在バグ候補・テスト不足を指摘候補として出してくれる。20 分／PR の目安
  • 所要時間・コスト：Claude Code + Cursor MCP で 1 週間、月数千円〜
  • 最初の壁：偽陽性（誤った指摘）の扱い。AI の指摘を鵜呑みにせず、人間レビュアーの判断を残す
  • 使うルート：A（Python + Cursor MCP 連携）

エンジニアの方は、私自身がコードレビューに AI を使っている領域で、業務での推進実感がいちばん強い使い方です。MCP の設定詳細は Cursor 使い方 に整理しています。

業務効率化の事例集として、5 領域 × 5 職種のマトリクスは別記事 AI 業務効率化 事例 と、ツール俯瞰は AI 業務効率化 ツール に整理しています。

12 — 失敗パターンと対処（業務で実際に使っているもの + 公開情報からの概論 分離）

📖 この章で使う用語

  • 最小権限の原則：エージェントに渡す道具・操作を、必要な範囲に絞る設計思想。
  • SLA（Service Level Agreement：サービス品質保証）：システムの稼働率・応答時間などの取り決め。
  • 評価設計：「エージェントが期待通り動いているか」を判定するためのテストケースの設計。
  • エッジケース：通常想定の外の、まれな入力ケース。エージェントが想定外の動きをしやすい領域。

私の業務で 4 ルートすべてを常用してきた中で見えた失敗パターンを、業務体験から書ける範囲 と 公開情報からの概論として紹介する扱い（業務常用ではない領域） に分けて整理します。

12-1. 業務エージェント構築の失敗パターン 5 つ（自分の経験ベース）

(1) 目的が曖昧なまま作り始める：「エージェントを作る」を目的にしてしまうと、何を任せたいかが固まらないまま技術選定だけが進みます。私の業務感覚では、「何を任せたいか」が先、技術選定は後 で進めるほうが結局いちばん早い、という型に落ち着きました。

(2) ツール定義の権限を広げすぎる：エージェントに「全部できる」を渡すと、ミスしたときの被害が大きくなります。最小権限から始めて、必要なら段階的に広げる方が安全です。たとえばメール送信の道具を渡すなら、最初は「下書き保存のみ」、確認後に「送信権限」を追加する、という段階を踏みます。

(3) 評価設計を後回しにする：「動いたっぽい」では本番に乗りません。私の業務でも、テストケースを 10〜20 個先に書いてから実装に入る型が結局効きます。エッジケース（想定外の入力）への振る舞いを先に決めておくと、運用に乗せたあとの調整がラクです。

(4) ノーコードで複雑な分岐を組みすぎる：ノーコード（ルート B）でも、条件分岐を 10 個も 20 個も重ねると可読性が一気に落ちます。私の業務感覚では、ノーコードで「組めるけど読めない」状態になったら、Python に切替時期、という判断軸を持っています。

(5) Projects / GPTs を「業務エージェント本番」と混同する：ルート D（Claude Projects / ChatGPT GPTs）は便利ですが、機密データ取り扱い・SLA・監視の観点で、本格的な業務エージェントとは別物です。私の業務でも、PoC・個人ツール・部内配布までは Projects / GPTs で組み、本番運用が必要になった段階で Python や Dify に移行する型を採ることが多いです。

12-2. 公開情報からの概論として紹介する扱い（業務常用ではない領域）

(6) ローカル LLM の精度を商用 API と同じと期待する：これは私の業務本番運用ではなく、個人検証レベルでの観察ですが、ローカル LLM（Ollama 等）に商用 API（Claude / ChatGPT / Gemini）と同じ精度を期待すると、用途によっては違和感が大きいです。一般論として、用途を絞る（特定タスクに特化させる、RAG で文脈を厚く渡す） 前提で考えるのが現実的、というのが業界での共通認識のひとつです。詳細は本記事 セクション 8「補足ルート」を参照してください。

評価設計の話は、RAG エージェントの文脈でも同じ論点が出てきます。RAG とは の周辺で「RAG の評価」も近いテーマとして扱っています。

13 — 法律・規約・セキュリティの注意（YMYL ゾーン）

📖 この章で使う用語

  • OSS ライセンス：オープンソースソフトウェアの利用条件（Apache 2.0 / MIT / Llama 3 利用許諾 等）。
  • Azure OpenAI：Microsoft Azure 上で OpenAI のモデルを使えるエンタープライズ向けサービス。データ取り扱いを契約で制御できます。
  • DLP（Data Loss Prevention：情報漏洩防止）：機密情報の流出を防ぐポリシー・仕組み。
  • テナント：組織単位で契約・管理される SaaS の利用単位。
  • コンプライアンス：法令・規制・社内ルールを遵守すること。

ここは YMYL（読者の人生・業務・金銭に影響しうる領域）ゾーンなので、「絶対大丈夫」とは申し上げません。私は弁護士ではなく、法令解釈・契約解釈の最終判断はできません。一次体験で「業務で詰まりやすい論点」を整理する立場で書きます。最終判断は、社内法務部門・コンプライアンス部門、必要に応じて弁護士へお願いしてください。

業務でエージェントを組むときに私が必ず押さえる 6 つの観点 を整理します。

(1) 利用規約の最新版確認：API プロバイダー（Anthropic / OpenAI / Google）、ノーコードツール（Dify / n8n / Make / Zapier）、Microsoft Copilot Studio、Claude Projects / ChatGPT GPTs、それぞれの利用規約は更新されることがあります。導入時点だけでなく、定期的な確認が必要です。

(2) 機密情報・個人情報を入力しない運用ルール：API はデフォルトで入力データを学習に使わない契約形態が一般的ですが、契約プラン（個人 / Team / Enterprise）によって異なります。Projects / GPTs の取り扱いポリシーも個別に確認が必要です。「業務で扱う最も機密度の高いデータを、このサービスに入れて大丈夫か」 を、入れる前に必ず情シス・法務に確認する運用が現実的です。

(3) 生成物の商用利用条件の確認：エージェントの出力（テキスト・コード・画像）を商用利用する場合、各サービスの規約で許諾範囲が異なります。著作権の帰属、商用利用可否、第三者の権利侵害の責任分界などは、案件ごとに確認が必要です。

(4) エージェントが自動で外部に書き込む操作の責任設計：メール送信・SaaS 投稿・データベース更新など、エージェントが外部に副作用を起こす操作は、責任設計が重要です。「誰の指示で」「何を」「いつ」「どの権限で」実行したかのログ を取れる仕組みを最初から組み込んでおくのが安全です。

(5) OSS LLM ライセンス条項：ローカル LLM を業務で使う場合、Llama 3 の利用許諾、Mistral の Apache 2.0 など、モデルごとに利用条件が異なります。商用利用可否・配布条件・トレーニング条項は、モデルごとに公式ライセンスを必ず確認してください。

(6) Microsoft Copilot Studio の組織管理ポリシー：テナント管理者の承認、DLP（情報漏洩防止）ポリシーの設定、社外共有可否などは、組織展開時の論点です。個人で試す段階と、組織展開する段階で、設計のレイヤーが変わります。

機密データを扱う案件では、AWS Bedrock 経由 / Azure OpenAI / ローカル LLM の 3 つが選択肢として候補に上がります。それぞれデータ取り扱いの契約条件・運用要件が違うので、社内の情シス・法務と一緒に選定する流れが一般的です。

繰り返しになりますが、最終判断は社内法務・コンプライアンス・必要に応じて弁護士へ。私の役割はあくまで「業務で詰まりやすい論点」を整理する立場までです。LLM 単体の YMYL 論点は LLM とは でも触れていますので、合わせて参照してください。

14 — まとめ：今週試す「最小の一手」

📖 この章で使う用語

  • 最小の一手：「今すぐ・短時間で・小さく」始められる、最初の 1 ステップ。
  • チュートリアル：公式が提供する「最初に動かす手順書」。

ここまで、AIエージェントの作り方を 4 ルート＋補足 1 ルート で整理してきました。改めて温度感をお伝えしておくと、ルート A〜D は、4 つすべて私が業務で常用している領域で業務で実際に使っているものとして書きました。補足ルートのローカル LLM だけは、私の業務では本番運用していませんので、個人検証レベルの感想に留めました。SERP 上位の競合記事は 1〜2 ルートに偏った構成が多い中で、4 ルートを業務で実際に使っているもので俯瞰した記事は、現時点で本記事の独自性のひとつだと考えています。

最後に、今週試せる 「最小の一手」 をルート別に整理します。重要なのは「比較を続ける」より「1 ルートを選んで手を動かす」ことです。

  • ルート A 派（Python）：API キーを取得 → 公式チュートリアル 1 本を写経（30 分）。本記事 4-1 のコードをそのまま動かすのもおすすめ
  • ルート B 派（ノーコード）：Dify Cloud Free にアカウント登録 → サンプルチャットボットを 1 個起動（30 分）
  • ルート C 派（Copilot Studio）：Microsoft 365 アカウントで Copilot Studio Trial を有効化 → ヘルプドキュメントの最初のサンプルを動かす（1 時間）
  • ルート D 派（Projects/GPTs）：Claude.ai Pro または ChatGPT Plus に既に課金している方は、今日 30 分で 1 個 Project / GPTs を作って動かしてみる

「迷ったらまず 1 ルートだけ手を動かす、比較は後でいい」というのが、4 ルートを通ってきた私の業務感覚です。やってみると、自分の前提（コード経験・社内環境・扱うデータ）に合うルートが、思ったより早く見えてきます。

次に読むなら、まず概念解説に戻る AIエージェントとは が一番自然です。その後の LLM 選び・Claude / ChatGPT エコシステムの深掘りは、末尾の関連記事から目的に合わせて辿ってください。

迷ったら、AIエージェントとは と本記事を読み返してから、今週 30 分だけ手を動かしてみる——それが現役の生成AIエンジニアとして、私が一番おすすめする入り方です。

15 — よくある質問（FAQ）

Q1. AIエージェントを作るのに、いくらかかりますか？

A. 最小サンプルなら無料クレジットで足ります。Anthropic / OpenAI ともに新規アカウントに無料クレジットが付与される運用で、1 回の実行コストは数円程度の感覚です。本格運用に乗せると月数百〜数千円〜の範囲。Dify Cloud / n8n Self-Hosted などノーコード派も Free プランで試せます。コードを書かない簡易構築なら、Claude Pro / ChatGPT Plus の月 $20 で Projects / GPTs が使えます。最新の金額は各社公式ページで必ず確認してください。

Q2. プログラミング初心者ですが、AIエージェントを作れますか？

A. ルート D（Claude Projects または ChatGPT カスタム GPTs）から始めるのが最も現実的だと私は考えています。コードを書かずに、Pro プラン $20/月で 30 分で 1 個作れます。次のステップとして、ノーコード（Dify Cloud / Zapier）→ Python と段階的に踏み出すのが、私の業務で観察した自然な流れです。完全コード未経験の方は、まずルート D で「動かす感覚」を手に入れるところから始めてみてください。

Q3. 個人開発で AIエージェントを作るのは、コスト的に大丈夫ですか？

A. 最小サンプルは API 無料クレジット内で完結します。本格運用に向けても、個人スコープなら月 1,000〜3,000 円程度から始められる現実感です。クレカ登録の心理的抵抗が最初の壁ですが、利用枠制限の設定で「うっかり数万円課金」を防げます。各社の API 料金ページは頻繁に更新されるので、最新の金額は公式ページで必ず確認してください。

Q4. ChatGPT / Claude / Gemini の API、どれを最初に選ぶべきですか？

A. 「絶対これ」とは申し上げません。私の業務では用途・コスト・既存スタックで使い分けています。個人で 1 つ選ぶなら、(1) 既に使っているチャットアプリのプロバイダーから始める、(2) 公式ドキュメントの読みやすさで決める、の 2 軸が現実的です。詳しくは LLM とは と Claude 使い方 を参照してください。

Q5. 業務で使うとき、機密情報の扱いはどうすればいいですか？

A. 「絶対大丈夫」とは申し上げません（私は弁護士ではありません）。一般論として、(1) API プロバイダーおよび Projects / GPTs / Copilot Studio のデータ取り扱いポリシーを事前確認、(2) 機密情報・個人情報を入力しない運用ルールを社内で合意、(3) 厳格な要件があれば AWS Bedrock / Azure OpenAI / ローカル LLM の選択肢、(4) 最終判断は社内法務・コンプライアンス部門へ——の 4 点が出発点になります。詳しくは本記事 セクション 13「法律・規約・セキュリティの注意」を参照してください。

私自身、現役の生成AIエンジニアとして 4 ルート（Python＋LangChain・ノーコード・Microsoft Copilot Studio・Claude Projects／ChatGPT GPTs）すべてを業務で使い分けている立場から、ルート選びと最小サンプルを実体験ベースか公開情報ベースかを分けて整理しました（ローカル LLM のみ個人検証レベル）。エージェント開発のツール・料金体系・利用規約・法的論点は変動が早いため、実際の利用判断は最新の公式情報と利用規約、社内ルール、必要に応じて法務・コンプライアンス部門の判断を優先してください。本記事に対する質問・誤りのご指摘は send@bon-bon-tools.com までお願いします。

関連記事

出典

新しい記事のお知らせを受け取る → 登録（準備中）