ChatGPTやGeminiに毎日同じ指示文を打ち込み、「この作業をAIに丸ごと任せられないか」と感じたことがあるエンジニアに向けた内容です。AIエージェント（LLMが自律的に判断しツールを呼び出しながらタスクを遂行する仕組み）の自作方法を、チャット型・自動化型・実行型という3つの実装パターンに分けて整理します。
どれも個人のPCやブラウザから無料枠で試せる範囲の話です。表面的な手順紹介ではなく、それぞれの方式が内部的に何をしているのか、LLMのアーキテクチャの違いとして見ていきます。
なぜ3方式に分かれるのか
AIエージェントという言葉は広く使われますが、実装の中身は大きく3種類に分解できます。
- チャット型: Geminiスキル・Claudeのプロジェクト機能などで、対話の中にシステムプロンプト（AIの振る舞いを固定する事前指示）を埋め込む方式
- 自動化型: n8nやDifyのようなワークフローツールで、トリガーとLLM呼び出しをノードとして接続する方式
- 実行型: Claude CodeやCodexのように、LLMがファイル操作やコマンド実行まで行う方式
この3つの違いは、単なる機能の多寡ではなく「LLMが扱うコンテキスト（会話や処理に渡される情報の範囲）の設計」が根本的に異なる点にあります。チャット型は会話履歴というコンテキストの中で完結し、自動化型は外部システムの状態をコンテキストに持ち込み、実行型はファイルシステムやシェル環境そのものをコンテキストの一部にします。
どの方式を選ぶかは、任せたい作業がどのコンテキストで完結するかで決まります。これは後述する判断基準につながる重要な分岐点です。
チャット型: システムプロンプトというファインチューニングの代替手段
チャット型のエージェント作成は、技術的には「ファインチューニング（モデルの重みを再学習させる手法）を使わずに振る舞いを固定する」方法です。
具体的な手順は4ステップで構成されます。
1. 任せる手順を指示文として書き出す
2. Geminiのスキル画面（カスタムGemの設定画面に相当）を開く
3. 名前・説明・指示をテンプレートに登録する
4. チャットで呼び出して指示文を試す
この方式の技術的な正体は、OpenAIのCustom GPTsやAnthropicのProjects機能と同じ「プロンプトエンジニアリングによる擬似パーソナライズ」です。モデル自体のパラメータは変わらず、毎回のリクエストに固定のシステムプロンプトが自動付与されているだけです。
そのためファインチューニングと比べて、専門知識の内在化はできません。たとえば社内の長大な規程集を丸ごと判断基準にしたい場合、プロンプトの長さには実用上の限界があり、コンテキストウィンドウ（モデルが一度に読める情報量の上限）を圧迫します。
こうしたケースでは、プロンプトに全文を詰め込むのではなく、RAG（Retrieval-Augmented Generation、検索によって必要な情報だけを都度取得しLLMに渡す手法）を組み合わせる設計が現実的です。チャット型のスキル機能だけで完結させようとせず、「固定ルールはシステムプロンプトに、可変知識はRAGに」と役割分担するのが、個人開発でも破綻しにくい設計です。
自動化型: ワークフローエンジンとLLM呼び出しの分離
n8nやDifyは、LLM APIの呼び出しを1つのノードとして扱い、前後にトリガーやデータ変換処理を接続できるツールです。
この方式が技術的に優れている点は、LLMの推論と、決定的な処理（API呼び出し・データ整形・条件分岐）を明確に分離できることです。LLMは確率的にテキストを生成するため、同じ入力でも出力が毎回微妙に変わります。
一方、情報収集やフォーマット変換といった工程は決定的に実行したい処理です。n8nのような構成では、不確実性を持つLLMノードを最小限の範囲に限定し、前後を決定的なノードで固めることで、エージェント全体の再現性を上げられます。
マイクロサービス設計に馴染みのあるエンジニアであれば、これは「LLMを1つのサービスコンポーネントとして疎結合に扱う」発想に近いと捉えると理解しやすいはずです。LLM呼び出し部分だけを後からClaude APIからGemini APIに差し替える、といった変更もワークフロー全体を壊さずに行えます。
実行型: エージェントがファイルシステムとシェルに触れる設計
Claude CodeやCodexに代表される実行型は、LLMにファイル操作やコマンド実行の権限まで渡す方式です。これは技術的にはMCP（Model Context Protocol、LLMと外部ツール・データソースを接続する標準プロトコル）や、各ツール独自のツール呼び出し（Tool Use / Function Calling）機構によって実現されています。
LLMはそれ自体ではファイルを読み書きできません。実行型エージェントは、LLMの出力を「どのツールをどの引数で呼ぶか」という構造化データとして解釈し、実際の実行はエージェント側のランタイムが担います。この「LLMは判断だけ行い、実行は外部に委譲する」構造は、RAGの検索部分を外部に切り出す設計思想と共通しています。
実行型を扱う際に確認すべきなのは、エージェントに与える権限の範囲です。Claude Codeであれば、どのディレクトリ内での操作を許可するか、どのコマンドを承認なしで実行してよいかという設定項目があります。これはモデルの性能とは別に、パイプライン設計として事前に見直しておく価値のあるポイントです。
今日確認できること
自分の環境でどの方式が現実的か判断するために、次の点を確認してみてください。
- 任せたい作業が「対話の中で完結するか」「外部システムの状態を参照する必要があるか」「ファイル操作が必要か」で3方式のどれに該当するか切り分ける
- 使っているLLMのコンテキストウィンドウの上限（GeminiやClaudeの各モデルのドキュメントに記載がある）を確認し、固定プロンプトで足りるかRAGが必要かを判断する
- n8nやDifyを試す場合は、LLMノードの前後にどれだけ決定的な処理を挟めるか、ワークフロー図を紙に描いてから着手する
- Claude Codeなど実行型を使う場合は、ファイルアクセスとコマンド実行の許可範囲を最初に設定で絞る
まとめ
AIエージェントの自作は、チャット型・自動化型・実行型のどれを選ぶかよりも、任せる作業がどの範囲のコンテキストで完結するかを見極めることが出発点になります。
チャット型はシステムプロンプトによる擬似パーソナライズであり、知識量が増えるならRAGとの併用を検討する余地があります。自動化型はLLMの確率的な振る舞いと決定的な処理を分離する設計、実行型はツール呼び出しによってLLMの判断と実行を切り離す設計です。
まずは手元の繰り返し作業を1つ選び、それが対話で閉じるのか、外部システムに触れる必要があるのか、ファイル操作まで必要なのかを書き出してみると、どの方式から着手すべきかが見えてきます。