1
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

@yoshisen(shigun)

AIエージェントを賢く働かせる設定術：ルールはAGENTS.md、手順はSKILL、知識はDocs、作業はChatへーー基礎知識の地図から、MCP・RAG・各社プラグインの活用、実践的なOSSツール、職種別の使い方まで

1
Last updated at Posted at 2026-10-28

本文は何を扱うのか

突き詰めれば本文は、「AIエージェントに何を読ませ、どう動かすか」を決めるための、設定ファイルの作り方ガイドである。AGENTS.md・SKILL・MCP接続・ループ処理の仕組みなど、エージェントが迷わず・無駄なく働けるようにするための、具体的で地味な設定術を扱う。

こうした営み全体を指して、2025年後半には "prompt engineering" に代わる呼び名としてコンテキストエンジニアリング（Context Engineering）という言葉が一時期広まった。LangChainのチームの定義を借りれば、「LLMがタスクを現実的にやり遂げられるように、適切な情報とツールを適切な形式で供給する動的なシステムを構築すること」とされる。ただし2026年に入ると、現場の語彙はさらに具体化・分化が進み、本文が扱うループエンジニアリング（Loop Engineering）、エージェントハーネス（Agent Harness）、**ソフトウェアファクトリー（Software Factory）**といった、より実装に即した言葉で語られることが増えてきた。本文もこの流れに合わせ、抽象的な理論よりも「実際に何のファイルを、どこに置き、どう繋ぐか」という具体的な設定術を中心に据える。

対象読者：

ソフトウェアエンジニア／ITエンジニア／データサイエンティスト／MLエンジニア、そしてChatGPT・Claude・Gemini・GitHub Copilot・Grokなどを仕事で使うすべての人

本文の鮮度について

このジャンルは驚くほど速く変化する。本文の執筆時点（2026年秋）で正確な情報も、半年後には製品名やプラン名が変わっている可能性が高い。一例を挙げる。

  • Googleの無料・個人向けエージェントCLIは、2026年6月に主な使われ方が「Gemini CLI」から「Antigravity CLI」へ移った
  • GitHub CopilotのMetrics APIは2026年4月に全面刷新された
  • NotebookLMは「Gemini Notebook」へ改称が進んでいる
  • ChatGPTの拡張機能は「Plugins」→「GPTs」→「Apps」→再び「Plugins」と、名称が行き来している

本文は考え方の地図を提供するものであり、固有名詞やURLは執筆時点のスナップショットである。実際に導入する際は、必ず公式ドキュメントで最新情報を確認してほしい。「この分野は名前がすぐ変わる」と心得ておくこと自体が、エージェント活用における重要な心得の一つである。

目次

  • Part 0. はじめに
  • Part 1. 地図を描く：AIエージェントとLLMの基礎
  • Part 2. エージェントに与える情報を設計する：4分類モデル
  • Part 3. エージェントの手足を広げる：アクセス方法・プラグイン・MCP・RAG
  • Part 4. 実践のためのOSSツール箱
  • Part 5. 職種・用途別の活用パターン
  • Part 6. 導入ロードマップ
  • まとめ：本質的な学び
  • 参考リンク集

Part 0. はじめに

ChatGPT、Claude、Gemini、GitHub Copilot、Grok……こうしたAIエージェントを仕事で使っていると、同じ説明を何度も入力してしまうことに気づく。

たとえば、次のような内容である。

  • 使用するプログラミング言語
  • コーディング規約
  • プロジェクトの背景
  • 業務上の制約
  • 作業の進め方
  • 出力フォーマット

最初のうちはチャットに直接入力しても問題ない。しかし、プロジェクトが長期化し、会話や資料が増えてくると、次のような課題が発生する。

  • 同じ内容を何度も説明する
  • 会話によって指示内容が変わる
  • 過去のチャットから必要な情報を探しにくい
  • 他のメンバーが同じ指示を再現できない
  • 長い資料を繰り返し貼り付けてしまう
  • AIエージェントの振る舞いが安定しない

そこで重要になるのが、AIエージェントに与える情報の「置き場所」を設計することだ。本文では、情報を次の4種類に分けて管理する方法を紹介する。

Global Rules   → AGENTS.md
Workflow       → SKILL
Knowledge      → Docs / Files
Current Task   → Chat

ひと言で表すと、次のようになる。

チャットを知識庫にしない。

長期的に利用する知識やルールはファイルやSKILLとして蓄積し、チャットには現在実行したいタスクだけを書く。この役割分担が、AIエージェント活用の生産性、再現性、保守性を大きく左右する。

本文は、この原則を軸にしながら、次の範囲まで扱う。

  1. Part 1 ―― そもそもエージェントとは何か、という基礎知識の地図
  2. Part 2 ―― 本文の中核である「4分類モデル」（情報設計の原則そのもの）
  3. Part 3 ―― エージェントへのアクセス方法、各社のプラグイン、MCP、RAG
  4. Part 4 ―― 設計支援・ルール管理・トークン節約・オーケストレーションを支える実践OSSツール
  5. Part 5 ―― 職種・用途別（ビジネス職／エンジニア／データサイエンティスト／クオンツ）の活用パターン
  6. Part 6 ―― 実際に導入するときの手順

Part 1. 地図を描く：AIエージェントとLLMの基礎

Part 2以降は実践的な話に集中するため、ここでは「エージェントとは何か」を短く地図化するだけにとどめる。体系的にもっと深く学びたい場合は、1.5節で紹介する大学講義のシラバスを参照してほしい。

1.1 エージェントとは何か

LLM単体は「尋ねられたら答える」だけの存在である。そこに次の要素が組み合わさると、環境を観測し、判断し、行動するというループを自律的に回すエージェントになる。

  • 外部ツールを呼び出す能力（Tool Use）
  • 状態を保持するメモリ
  • 次の一手を決めるプランニング
  • 結果を観測して軌道修正するループ

このループを実際に動かす実行基盤――LLM呼び出し、ツール実行、結果の要約をひとまとめにしたプログラム――を、業界では**ハーネス（harness）**と呼ぶ。

"An agent harness is the loop that drives an LLM. It sends a prompt, gets a response, executes the tool calls the model requested, feeds the results back, and repeats until the model says it's done. Every production agent has one."
――エージェントハーネスとは、LLMを駆動するループそのものである。プロンプトを送り、応答を受け取り、モデルが要求したツール呼び出しを実行し、結果をフィードバックし、モデルが「完了」と言うまで繰り返す。すべての本番エージェントはこれを持っている。

OpenAIのAgents SDKのドキュメントやAnthropicの社内ツールでも「harness」という語がそのまま使われており、業界標準の語彙になりつつある（mini-swe-agentは近い意味で"agent scaffold"という語を使うなど、プロジェクトによって多少の呼び方の揺れはある）。GitHub Copilot CLI、Claude Code、Codex CLI、OpenHands、xAIの「Grok Build」は、いずれも「同じLLMに違うハーネスを着せたもの」と理解すると見通しがよい。

1.2 エージェントを支える中核能力

能力 一言でいうと 本文との対応
Tool Use（ツール利用） 検索・コード実行・API呼び出しなど、外側の機能を呼び出す Part 3のMCPがこの能力を標準化する
Context Management（コンテキスト管理） 有限なコンテキストウィンドウの中で何を残し何を圧縮するか Part 4のトークン節約ツールが対応
Memory & Skills（記憶とスキル） セッションをまたいで再利用できる知識・手順を持たせる Part 2のSKILLがこれに対応
Planning & Multi-Agent（計画と協調） 大きなタスクを分解し、必要ならサブエージェントに分担させる Part 4のオーケストレーションフレームワークが対応
Training（学習） SFT・強化学習によってモデル自体を改善する 直接手を動かす部分ではないが、モデルの得意・不得意の理解に役立つ

1.3 代表的な応用領域

  • コーディングエージェント ―― 本文が最も重点を置く領域。GitHub Copilot、Claude Code、Codex、OpenHands、Grok Buildなど
  • コンピュータ操作エージェント（Computer Use） ―― 画面を直接操作する。Anthropic Computer Use、ブラウザ操作エージェント（browser-use等）など
  • ディープリサーチエージェント ―― Web検索と情報統合を自律的に繰り返す。ChatGPTのDeep Research、Geminiのリサーチ機能など

1.4 安全性・評価のひとこと

  • Safety（安全性） ―― エージェントが意図しない操作（機密情報の送信、破壊的コマンドの実行）を行わないための設計。OWASP LLM Top 10など（Part 4.5で詳述）
  • Evaluation（評価） ―― SWE-bench、τ-benchのようなベンチマークで実力を定量的に測る（Part 4.6で詳述）

1.5 体系的に学びたい人のための「大学の目次」

地図をさらに深めたい人には、大学講義のシラバスを「目次」として眺めるのがおすすめである。本文執筆時点で公開されている2つを紹介する。

Carnegie Mellon University「11-768 AI Agents」（https://www.cmu-agents.com/#/schedule ）

  • 導入と中核能力：エージェントとは何か／Tool Use／長文脈管理／スキルと記憶／プランニングとマルチエージェント協調
  • 応用領域：コーディングエージェント／コンピュータ操作エージェント／ディープリサーチエージェント
  • 学習方法：SFT／RLの基礎と応用／RLシステム
  • 安全性とフレームワーク：エージェントの安全性／観測可能性／フレームワーク／オーケストレーション
  • 相互作用と探索：人間とエージェントの協調／リランキングと批評モデル／木探索

Stanford University「CS146S: The Modern Software Developer」（https://themodernsoftware.dev/ 、担当：Mihail Eric）

  • MCP、Agent Skills、仕様駆動開発（Spec-Driven Development）、「ループエンジニアリング（loop engineering、詳しくは1.6で扱う）」、「ソフトウェア工場（software factory）」という5本柱
  • OpenHands、Milvus、Marimo、CrewAI、Warp、Arize Phoenix、Unsloth、Anyscale、Semgrepなど、実務のOSSプロジェクトがスポンサーとして名を連ねる、現場感の強い構成

どちらも「エージェントを使う人」ではなく「エージェントを作る・組み込む人」向けだが、目次を眺めるだけでもこの分野の全体像がつかめる。本文のPart 3・4は、この地図を日々の実務に落とし込んだものと言える。

現場の声から学ぶ：体系立ったカリキュラムだけでなく、実際にエージェントを作っている実務家の発言も参考になる。Claude Codeの開発をリードするBoris Cherny（Anthropic）は、2026年1月に自身のX（旧Twitter）で、Claude Codeの実際の使い方を13個のヒントとして公開した。「チーム全員でひとつのCLAUDE.mdをGitにコミットし、Claudeが間違えるたびに追記していく」「厳密なプランモードから始める」「複数のworktreeでエージェントを並列実行する」といった具体的な運用であり、詳しくはPart 5.2で紹介する。また、xAIでReactコンパイラとエージェント開発の両方に関わるLauren Tan（X: @poteto）が投げかけた「自分はいま何体のエージェントを同時に働かせているか」という問いは、エージェント時代のエンジニアの生産性を測る新しい指標として話題になった。あくまで「エージェントを実際に作っている人の発言は、カリキュラム以上に実務の参考になる」という一例として紹介する。

1.6 ループエンジニアリング（Loop Engineering）――指示するのをやめて、ループを設計する

前節で名前だけ挙げた「ループエンジニアリング」は、2026年に入って急速に広まった、きわめて実務的な考え方である。要点は一言で言える。

エージェントに毎回「指示」するのをやめ、エージェントに指示を出し続ける「仕組み（ループ）」そのものを設計する。

開発者Peter Steinbergerの言葉を借りれば、

"You shouldn't be prompting coding agents anymore. You should be designing loops that prompt your agents."
――もうコーディングエージェントに逐一プロンプトを打つべきではない。エージェントにプロンプトを与え続けるループを設計すべきだ。

Claude Codeの開発をリードするBoris Chernyも、同じ時期にこう述べている。

"I don't prompt Claude anymore. I have loops running that prompt Claude and figuring out what to do. My job is to write loops."
――もう私はClaudeにプロンプトを打たない。Claudeにプロンプトを与え、次にやることを判断するループを走らせている。私の仕事はループを書くことだ。

ループを構成する6つの要素

ブロガーのAddy Osmaniは、CodexアプリとClaude Codeの両方を比較しながら、実務的なループが共通して持つ要素を6つに整理している。

要素 ループの中での役割 具体例（Codex app / Claude Code）
Automations（自動実行） 決まったタイミングで発見・トリアージを自律的に行う"心臓部" Automationsタブで定期実行 ／ /loop・cron・hooks・GitHub Actions
Worktrees（作業ツリー） 複数エージェントを並列実行しても、ファイルが衝突しないよう隔離する 組み込みのworktree ／ git worktree・--worktree・サブエージェントのisolation: worktree
Skills（本書のSKILLに相当） プロジェクト固有の知識を書き残し、エージェントが毎回ゼロから推測しなくて済むようにする $nameで呼び出すSKILL.md ／ 同じくSKILL.md形式
Plugins / Connectors（MCPに相当） エージェントを実際のツール（Issue管理、Slack、DBなど）に接続する MCP経由のConnectors ／ MCPサーバー＋プラグイン
Sub-agents（サブエージェント） 「作る人」と「確認する人」を分離する TOML定義の.codex/agents/ ／ .claude/agents/とエージェントチーム
State（状態の記録） 会話の外側に「何が終わり、何が残っているか」を記録する記憶装置 Markdownファイル／Linear連携 ／ AGENTS.mdや進捗ファイル、Linear連携

この表を見ると分かるとおり、ループエンジニアリングの6要素のうち4つまでは、本書がすでに扱ってきた概念の運用形態にすぎない。SkillsはPart 2.2のSKILL、Plugins/ConnectorsはPart 3.2のMCP、Sub-agentsはPart 4.4のオーケストレーション、StateはPart 2.3のDocs（または進捗を記録する専用ファイル）に、それぞれ対応している。ループエンジニアリングが新しく付け加えるのは、主にAutomations（スケジュール実行）とWorktrees（並列隔離）という「いつ・どう動かすか」の部分である。

具体的な仕組み（Claude Codeを例に）

  • /loop ―― 一定間隔でプロンプトを再実行する
  • /goal ―― 「test/authのテストが全て通り、lintがクリーンな状態」のような検証可能な停止条件を自分で書き、それが満たされるまでターンをまたいで実行し続ける。しかも「完了したかどうか」の判定は、作業した本人（同じモデル）ではなく、別の小さなモデルが行う。作る人と採点する人を分離するという発想は、人間のコードレビューにも通じる

過信してはいけない理由

ループエンジニアリングは強力だが、免罪符ではない。Addy Osmaniは次のように釘を刺している。

  • 検証は依然として人間の仕事である ―― 無人で動くループは、無人でミスも生み出す。「完了した」というのはあくまで主張であり、証明ではない
  • 理解の負債（comprehension debt）が加速する ―― ループが速く多くのコードを生み出すほど、「実際に存在するコード」と「自分が理解しているコード」の差は開きやすくなる
  • 思考停止（cognitive surrender）のリスク ―― ループが自律的に動くようになると、出てきた結果をそのまま受け入れたくなる誘惑が強まる

"Build the loop. But build it like someone who intends to stay the engineer, not just the person who presses go."
――ループを作るのはよい。ただし、「ボタンを押すだけの人」ではなく、「エンジニアであり続けるつもりの人」として作ること。

また、スケジュール実行されるループは、気づかないうちにトークン消費が積み上がりやすいという実務上の注意点もある。可観測性ツール（Part 4.5）で消費量を継続的に監視する体制とセットで導入すべきである。

Part 2. エージェントに与える情報を設計する：4分類モデル

2.0 情報の置き場所は「利用期間」と「再利用性」で決める

AIエージェントに与える情報の置き場所を決めるとき、トークンコストだけを基準にするのは適切ではない。より重要なのは、次の2つの観点である。

1. どのくらい長く利用するか

  • 今回の作業だけで使う
  • 同じプロジェクト内で繰り返し使う
  • 複数のプロジェクトで共通利用する

2. どこまで再利用するか

  • 一度だけ使う指示
  • 特定の作業で利用する手順
  • プロジェクト全体で守るルール
  • 長期的に参照する業務知識

この2つの軸で整理すると、情報の置き場所を判断しやすくなる。

毎回守るルール          → AGENTS.md
特定の作業で使う手順     → SKILL
長期間参照する知識・資料 → Docs / Files
今回だけ実行する依頼     → Chat

2.1 共通ルールはAGENTS.mdに書く

プロジェクト全体で常に守らせたいルールは、AGENTS.mdに記載する。

AGENTS.mdは、もはや一社だけの慣習ではない。 2025年にOpenAIなどが主導して公開された、コーディングエージェント向けのオープンな標準フォーマットであり、公式サイト（agents.md）は「60,000以上のオープンソースプロジェクトで使われている、エージェント向けのREADME」と位置づけている。GitHub Copilotを含め、多くのツールがこのファイルをネイティブに読み込む。

ただし、ツールによっては独自の名前を使う場合もある。

ファイル名 主に読み込むツール
AGENTS.md ベンダー中立のオープン標準。GitHub Copilotも含め多くのツールが対応
CLAUDE.md Claude Code（GitHub Copilotも読み込む）
GEMINI.md Gemini CLI / Gemini Code Assist（GitHub Copilotも読み込む）
.github/copilot-instructions.md GitHub Copilot（リポジトリ単位のカスタム指示）

実務的には、複数ツールを併用するチームほど、内容が重複しないようAGENTS.mdを正本にし、他のファイルはそれを参照するだけにする、という運用が望ましい。

AGENTS.mdに適した情報

たとえば、次のような内容である。

  • 使用言語
  • コーディング規約
  • 命名規則
  • 出力フォーマット
  • テスト方針
  • レビュー基準
  • セキュリティ上の制約
  • 使用するライブラリ
  • 禁止事項
  • 回答に含めるべき項目

記述例

# Project Rules

## Language

- 説明とドキュメントは日本語で記述する
- 変数名と関数名は英語にする

## Python

- Python 3.12以上を使用する
- 環境管理にはuvを使用する
- 型ヒントを付ける
- 関数にはdocstringを記述する
- データ量が多い場合はPolarsの利用を検討する

## Testing

- 新しい機能にはテストを追加する
- テストにはpytestを使用する
- 正常系だけでなく異常系も確認する

## Output

- 変更内容を最初に要約する
- 変更したファイルを一覧化する
- 実行したテストと結果を記載する
- 未解決のリスクがある場合は明記する

AGENTS.mdを利用するメリット

共通ルールをチャットから分離することで、次の効果が期待できる。

  • 会話ごとに同じ指示を繰り返さなくてよい
  • プロジェクト全体でAIの振る舞いを統一できる
  • ルールをGitで管理できる
  • チームメンバー間で同じ指示を共有できる
  • ルールの変更履歴を確認できる
  • プロンプトの属人化を減らせる

AGENTS.mdは、AIエージェント向けの設定ファイルであると同時に、プロジェクトの開発方針を明文化するドキュメントでもある。

書きすぎには注意する

一方で、すべての情報をAGENTS.mdに詰め込むべきではない。AGENTS.mdが長くなりすぎると、次のような問題が起こる。

  • 重要なルールが埋もれる
  • 関係のない作業でも大量の指示が適用される
  • ルール同士が矛盾する
  • 更新の影響範囲が分かりにくくなる

したがって、AGENTS.mdには「ほぼすべての作業で守る必要があるルール」だけを置くのがよい。

2.2 特定業務の手順はSKILLとして管理する

コードレビュー、テスト、データ分析、モデル評価など、特定の作業でのみ利用する手順はSKILLとして管理する。ここでいうSKILLとは、特定のタスクを実行するときに参照する、再利用可能な作業手順や判断基準である。

SKILLも標準化が進んでいる。 AnthropicはAgent Skillsという名前でこの概念をオープンな仕様として公開しており（agentskills.io）、実体はSKILL.mdというファイルを含むフォルダである。設計上の工夫は**段階的開示（progressive disclosure）**にある。

  1. Discovery ―― 起動時には各SKILLの名前と説明文だけを読み込む
  2. Activation ―― タスクが説明文に合致したときだけ、SKILL.mdの本文を読み込む
  3. Execution ―― 本文の指示に従い、同梱スクリプトや参考資料を使う

この仕組みのおかげで、大量のSKILLを用意しても、エージェントのコンテキストを圧迫しない。

興味深いことに、この発想は研究の現場でも実践されている。著名な研究者Andrej Karpathyが公開した実験的リポジトリautoresearchでは、AIエージェントに小さなLLM学習コードを一晩中自律的に改善させる。その際、人間が書くのはprogram.mdというMarkdownファイルだけであり、Karpathy自身がREADMEで「program.mdは実質的に、ごく軽量な"skill"である」と述べている（詳しくはPart 5.3）。SKILLという発想は、コーディング支援だけでなく、自律的な研究開発にまで応用され始めている。

SKILLに適した情報

たとえば、次のような作業である。

  • コードレビュー
  • テスト設計
  • 要件分析
  • 障害調査
  • EDA
  • 特徴量設計
  • モデル評価
  • リリース判定
  • 技術文書作成
  • インシデント対応

コードレビューSKILLの例

# Code Review Skill

## Purpose

変更されたコードの品質、保守性、安全性を確認する。

## Procedure

1. 変更目的を確認する
2. 差分と影響範囲を確認する
3. 正常系と異常系を確認する
4. テストの有無と妥当性を確認する
5. セキュリティ上の問題を確認する
6. パフォーマンスへの影響を確認する
7. 修正提案を優先度別に整理する

## Output Format

- Summary
- Critical Issues
- Major Issues
- Minor Issues
- Suggested Changes
- Test Recommendations

SKILLとして分離するメリット

共通ルールと専門的な手順を分離すると、情報の役割が明確になる。

AGENTS.md
└─ いつでも守る基本方針

SKILL
└─ 特定の作業を実行する手順

たとえば、「Pythonでは型ヒントを使う」という指示は共通ルールである。一方、「モデル評価では時系列リークを確認する」という指示は、機械学習モデルを評価するときに必要な専門手順である。

両方をAGENTS.mdに書くこともできるが、ルールが増えるほど管理が難しくなる。特定タスクに依存する手順はSKILLに分離した方が、再利用性と保守性が高まる。

なお、SKILLのディレクトリ構造や読み込み方法は、AIエージェント製品によって異なる。ここでは、特定タスクの手順を共通ルールから分離するという設計思想を重視している。

2.3 長期間利用する資料はDocsまたは外部ファイルに置く

仕様書、設計書、業務知識、KPI定義など、長期的に参照する情報は外部ファイルとして管理する。

ファイルとして管理する情報

代表的な例は次のとおりである。

docs/
├─ requirements.md
├─ architecture.md
├─ business.md
├─ metrics.md
├─ domain.md
├─ data_dictionary.md
└─ decisions/
    ├─ adr-001-model-selection.md
    └─ adr-002-evaluation-policy.md

それぞれの役割は次のように整理できる。

  • requirements.md: 機能要件、非機能要件
  • architecture.md: システム構成、技術選定
  • business.md: 業務背景、解決したい課題
  • metrics.md: KPIや評価指標の定義
  • domain.md: 業界用語、業務ルール
  • data_dictionary.md: カラム、型、欠損値、意味
  • decisions/: 重要な設計判断とその理由

チャットではなくファイルに残す理由

チャットの履歴だけに重要な知識を残すと、次の問題が発生する。

  • 会話が終了すると見つけにくくなる
  • 別のAIエージェントから再利用しにくい
  • チームメンバーが参照できない
  • 内容の更新履歴を管理しにくい
  • どの情報が最新なのか判断しにくい

一方、ファイルとして保存すれば、AIとの会話が終了しても知識資産として継続的に利用できる。また、Gitで管理すれば、誰が、いつ、何を変更したのかを確認できる。

ファイル化は必ずしもコスト削減ではない

注意すべき点として、資料をファイルに置いただけで、必ずトークン消費が減るとは限らない。AIエージェントがファイルを読む場合、その内容は最終的にモデルのコンテキストへ渡される。また、エージェントがファイルを検索・読み込みするための処理も発生する。

したがって、ファイルを使う主な目的は、単純なコスト削減ではない。主な目的は次のとおりである。

  • 知識を永続化する
  • 必要なときに読み直せるようにする
  • チームで共有する
  • バージョン管理する
  • チャットと知識を分離する
  • プロジェクトを再現可能にする

同じ資料を毎回チャットへ貼り直す方法と比べれば効率化できる可能性があるが、「ファイルにすれば常に安くなる」とは限らない点に注意が必要である（本当にトークンを削減したい場合は、Part 4.3で紹介するCodeGraphやrepomixのような専用ツールの出番になる）。

2.4 今回だけの依頼はチャットに書く

その時点で実行したい作業は、チャットで具体的に指示する。

チャットに適した指示

  • 第3章を修正する
  • テストコードを追加する
  • 売上データのグラフを作成する
  • このエラーの原因を調査する
  • モデルAとモデルBの結果を比較する
  • READMEを更新する
  • 現在の差分をレビューする

指示例

docs/metrics.mdの評価指標を参照し、
notebooks/baseline.ipynbのモデル評価を実施してください。

evaluation Skillの手順に従い、次の内容を出力してください。

1. 評価結果
2. ベースラインとの差
3. データリークの可能性
4. 過学習の有無
5. 本番導入前に必要な追加検証

この指示では、すべてをチャットに書き直していない。

  • 評価指標はdocs/metrics.md
  • 評価手順はevaluation Skill
  • 今回の対象はnotebooks/baseline.ipynb
  • 今回必要な出力だけをチャットで指定

という役割分担になっている。

「先ほどの資料」ではなく名前で参照する

会話が長くなると、「先ほどの文章」や「前のファイル」という表現は曖昧になる。可能であれば、対象を具体的に指定する。

悪い例：
先ほどの資料を修正してください。

良い例：
docs/business.mdの「対象ユーザー」セクションを修正してください。

資料名、ファイル名、見出し、関数名などを明示すると、AIエージェントが対象を誤認するリスクを減らせる。

2.5 4種類の役割を整理する

ここまでの内容は、次のようにまとめられる。

分類 目的 例
AGENTS.md 常に守るルールを定義する 使用言語、コーディング規約、テスト方針、出力形式、禁止事項
SKILL 特定タスクの標準手順を定義する コードレビュー、EDA、モデル評価、障害調査、リリース判定
Docs / Files 長期的に参照する知識を保存する 要件、設計、業務知識、KPI定義、データ辞書、意思決定記録
Chat 現在実行するタスクを指示する 修正対象、今回の作業範囲、期待する成果物、優先順位、期限や制約

つまり、理想的な役割分担は次のとおりである。

ルールはAGENTS.md、手順はSKILL、知識はDocs、作業はChat。

2.6 よくあるアンチパターン

アンチパターン1：同じ資料を毎回貼り直す

1回目：仕様書の全文を貼る
2回目：同じ仕様書の全文を再び貼る
3回目：修正版の全文をもう一度貼る

同じ内容を何度も入力すると、コンテキストが増え、どの版が最新なのか分かりにくくなる。

改善方法：

1回目：資料をファイルとして保存する
2回目以降：ファイル名と対象セクションを指定する

アンチパターン2：すべてをAGENTS.mdに書く

AGENTS.mdに業務知識、作業手順、今回の依頼まで書くと、ファイルが肥大化する。

改善方法：

共通ルール → AGENTS.md
専門手順   → SKILL
業務知識   → Docs
今回の依頼 → Chat

アンチパターン3：重要な判断がチャットにしか残っていない

たとえば、モデルを選定した理由がチャット履歴だけに残っていると、数か月後に判断経緯を追跡できない。

改善方法：

docs/decisions/
└─ adr-001-model-selection.md

# モデル選定

## Decision

LightGBMを採用する。

## Context

表形式データであり、欠損値とカテゴリ変数を含む。

## Alternatives

- Logistic Regression
- Random Forest
- XGBoost
- Neural Network

## Reason

ベースラインより高い精度を示し、推論時間と説明可能性の要件を満たした。

## Risks

データ分布の変化により性能が低下する可能性がある。

アンチパターン4：情報の正本が分からない

同じKPIの定義がAGENTS.md、チャット、README、設計書に分散していると、どれが正しいのか分からなくなる。

改善方法：

  • KPIの正式な定義はdocs/metrics.mdに集約する
  • AGENTS.mdには「評価時はdocs/metrics.mdを参照する」と書く
  • チャットには今回利用する指標だけを書く

「同じ情報を複数の場所にコピーする」のではなく、「正本を一つ決めて参照する」ことが重要である。

Part 3. エージェントの手足を広げる：アクセス方法・プラグイン・MCP・RAG

Part 2までは「エージェントに何を読ませるか」という話だった。Part 3では「エージェントをどう使うか」「エージェントに何をつなぐか」を扱う。

3.1 アクセス方法の基本形

同じエージェントでも、アクセスの形態によって向いている作業が変わる。

形態 特徴 向いている用途
Web（ブラウザ） ログインするだけ、環境構築不要 調べ物、文章作成、画像生成
デスクトップアプリ OS通知、グローバルショートカット、常駐 日常的な相談、画面共有
モバイルアプリ 外出先、音声入力 移動中の相談、音声対話
CLI（ターミナル） リポジトリ直下で動く、ファイル操作・git操作が可能、複数インスタンスの並列実行が可能 コーディングエージェント
IDE拡張機能 エディタ内でインライン補完・チャット・Agent Mode 日常の開発作業
API / SDK プログラムから呼び出す 自社ツールへの組み込み、自動化、CI/CD
ブラウザ拡張機能 閲覧中のページを読んで操作する リサーチ、フォーム入力

実務上は、1つの形態に絞る必要はない。「設計はWeb版でじっくり相談し、実装はCLIで並列に走らせ、レビューはIDE拡張機能で確認する」といった使い分けが一般的になりつつある。実際、Claude Codeの開発者であるBoris Chernyは、5つのgit worktreeでClaude Codeを並列実行し、さらにWeb版（claude.ai/code）でも5〜10セッションを同時に走らせていることを公開している。「エージェントを何体同時に働かせているか」が、ひとつの生産性の指標になりつつある。

3.2 MCP（Model Context Protocol）

MCPとは何か。 MCPは、AIアプリケーションを外部のデータソースやツールに接続するためのオープンな標準規格である。元々はAnthropicが2024年11月に公開したが、2025年12月にはAnthropic・Block・OpenAIが共同設立した「Agentic AI Foundation」（Linux Foundation傘下）に移管され、特定企業だけのものではなくなった。公式サイトは「AIアプリケーションのためのUSB-Cポートのようなもの」と説明している。

MCPが解決する問題はシンプルである。従来、AIをN個のツールに接続するには、ツールの数だけ個別の連携コードを書く必要があった。MCPはこれを「M個のクライアント × N個のサーバー」の組み合わせ爆発ではなく、共通プロトコル1つに置き換える。

よく使われるMCPサーバーの例

サーバー できること
Filesystem ローカルファイルの読み書き（アクセス制御付き）
Git / GitHub（github/github-mcp-server） リポジトリの操作、Issue・PRの作成
Playwright（microsoft/playwright-mcp） ブラウザ自動操作（アクセシビリティツリー経由）
Context7（upstash/context7） ライブラリの最新ドキュメントを取得し、古いAPIの幻覚を防ぐ
Slack / Notion / Figma チャットやドキュメント、デザインファイルとの連携
Postgres / SQLite データベースへの問い合わせ
Sequential Thinking / Memory 思考過程の整理、知識グラフ型の永続メモリ

レジストリ（探し方）

  • 公式レジストリ：registry.modelcontextprotocol.io
  • コミュニティのマーケットプレイス：Smithery.ai
  • Docker MCP：コンテナ化されたMCPサーバーのカタログ／ゲートウェイ

実務上の注意点として、公式のreference実装（modelcontextprotocol/servers）は意図的に最小限（Everything, Fetch, Filesystem, Git, Memory, Sequential Thinking, Time）に絞られており、GitHub連携などの「よく使うもの」は各社が自分のリポジトリで直接メンテナンスしている。導入前に、そのMCPサーバーが誰によってメンテナンスされているか、どこまでの権限を要求するかを確認したい。

3.3 各エージェントの利用形態とプラグイン早見表（2026年時点）

注意：この分野は毎月のように名称やプランが変わる。以下は執筆時点のスナップショットであり、実際に使う前に必ず公式ドキュメントを確認してほしい。

3.3.1 ChatGPT（OpenAI）

  • アクセス方法：Web（chatgpt.com）、デスクトップアプリ（Mac/Windows）、モバイルアプリ（iOS/Android）、独自ブラウザ「ChatGPT Atlas」、API（platform.openai.com）
  • 拡張機能の歴史：Plugins（2023年3月）→ GPT Builder／「GPTs」（2023年11月）→ GPT Storeでの公開（2024年1月）→ MCP対応の「developer mode」追加（2025年9月）→ 呼び名が再び「plugins」に戻る（2026年7月）、という変遷をたどっている。名称が頻繁に変わること自体が、このジャンルの特徴だと捉えるとよい
  • 主な機能：Code Interpreter（コード実行・データ分析）、Canvas（共同編集）、Deep Research（自律的なWebリサーチ）、Connectors（Google Drive・SharePointなど社内データとの接続）、Codexエージェント（自律コーディング）、ブラウザ操作機能を統合した「ChatGPT agent」

3.3.2 Claude（Anthropic）

  • アクセス方法：Web（claude.ai）、デスクトップアプリ、モバイルアプリ、CLI「Claude Code」（curl -fsSL https://claude.ai/install.sh | bash または winget install Anthropic.ClaudeCode）、API、GitHub上で@claudeとメンションして起動
  • 主な機能：
    • Projects / Artifacts ―― 資料をまとめて参照させるプロジェクト機能、生成物をプレビューしながら編集できるArtifacts
    • Agent Skills ―― 本文のSKILLの標準化版（2.2節参照）。anthropic/skillsリポジトリに実例が公開されている
    • Claude Plugins ―― .claude-plugin/plugin.jsonで構成されるプラグイン機構。/plugin installで導入する
    • MCPB（MCP Bundles） ―― ローカルMCPサーバーをワンクリックで導入するための配布形式。以前は「.dxt（Desktop Extensions）」と呼ばれていたが「.mcpb」に改称された
    • Computer Use ―― 画面を直接操作するエージェント機能のリファレンス実装

3.3.3 Gemini（Google）

  • アクセス方法：Web、モバイルアプリ、Gemini Code Assist（VS Code / JetBrains / Android Studio拡張機能）、API（Google AI Studio / Vertex AI）
  • 変化が大きい領域（要注意）：無料・個人向けのコーディングエージェントCLIは、2026年6月18日付けで「Gemini CLI」から新製品「Antigravity CLI」（コマンドagy）へと主要な使われ方が移った。残った「Gemini CLI」は、Google Cloud上のGemini Code Assist Standard/Enterprise向けの企業利用に位置づけが変わっている。ステートレスにAPIを叩くだけの「Gemini API CLI」という軽量ツールも別途存在する
  • Gemini Code Assist：Standard版（コード補完・チャット・ローカルコードベース理解）とEnterprise版（自社コードでのカスタマイズ、Apigee等との連携）の2エディション
  • Gemini Notebook：音声・動画の自動生成、資料の要約で知られる「NotebookLM」から改称が進んでいるツール
  • Workspace・Maps・YouTubeなどと連携する「Gemini Extensions」や「Gems」は2024年以降の定番機能だが、具体的な現在の仕様は公式ドキュメントで確認してほしい

3.3.4 Grok（xAI）

  • アクセス方法：Web（grok.com）、X（旧Twitter）アプリ内統合、モバイルアプリ、API（x.ai、公式SDKはxai-sdk）
  • コーディング特化モデル：「Grok Code Fast 1」という高速・低コストなコーディング特化モデルを公開しており、GitHub Copilotでも選択可能なモデルの一つとして提供されている（自社製品に閉じず、他社ツールにも展開している点が特徴）
  • CLIエージェント「Grok Build」：grokというターミナル常駐型のコーディングエージェント（TUI）。ファイル編集、シェルコマンド実行、Web検索をこなし、対話・ヘッドレス（CI向け）・エディタ埋め込み（Agent Client Protocol経由）のいずれでも動く。MCPサーバーにも対応する。設計思想としてはClaude CodeやCodex CLIに近く、実際に両者のコードの一部を取り込んでいることが公開されている
  • 位置づけ：ChatGPT・Claude・Geminiが「自社の統合エコシステム」を競うのに対し、Grokは「X上のリアルタイムデータへのアクセス」と「他社ツールにも載る高速・低価格のコーディングモデル」を強みにしている

3.3.5 GitHub Copilot（Business / Enterprise を含む）

GitHub Copilotは、個人の開発支援ツールから、企業向けのプラットフォームへと役割を広げている。

アクセス方法

  • IDE拡張機能：VS Code、Visual Studio、JetBrains系IDE、Xcode、Eclipse、Neovim
  • Web：github.com上のCopilot Chat、Copilot Spaces（Freeプランでも利用可）
  • CLI：copilotコマンド（対話モードとプランモード、プログラム的に呼び出すモードの両方を持つ。Linux/macOS/WindowsのPowerShellおよびWSLに対応）
  • モバイル：GitHub Mobileアプリからのチャット
  • Copilot coding agent ―― クラウド上で非同期に動作し、Issueを受け取って自律的にPull Requestを作成する自律型エージェント
  • Agent apps（旧称「Copilot Extensions」）―― MCPとJWT認証を基盤にした、サードパーティ製のエージェント向けマーケットプレイス

カスタマイズの全体像

GitHub自身のドキュメントは、カスタマイズの仕組みを次のように整理している（それぞれ独立した概念である点に注意）。

  • Custom instructions（カスタム指示）
  • Agent skills
  • Tools
  • MCP servers
  • Hooks
  • Subagents
  • Custom agents
  • Extensions / Plugins

カスタム指示は3段階のスコープを持つ。

種類 適用範囲 用途の例
Personal instructions 自分とCopilotとの会話全般 個人の好みの言語・回答スタイル
Repository custom instructions 特定のリポジトリ・プロジェクト内 使用言語、フレームワーク、アーキテクチャ、コーディング規約
Organization custom instructions 組織全体 組織共通の言語・セキュリティ・コンプライアンス方針

興味深いことに、GitHub CopilotはAGENTS.md・CLAUDE.md・GEMINI.mdのいずれもネイティブに読み込む。つまり、他社のエージェント向けに書いたルールファイルを、Copilotがそのまま再利用できるということである。これは、Part 2で述べた「正本を一つに決めて参照する」という原則を、マルチベンダー環境でも実現しやすくしている。

プラン比較（企業導入の参考として）

プラン 主な対象
Free / Student 個人・学習用途、機能は限定的
Pro / Pro+ / Max 高度な利用をしたい個人（モデル選択肢・利用量が段階的に拡大）
Business 組織・企業向け。ポリシー管理、組織単位のカスタム指示に対応
Enterprise GitHub Enterprise Cloudを使う大企業向け。Businessの全機能に加え、より大きな利用枠と企業向け機能を追加

課金は「GitHub AI Credits」という共通クレジット制度に統一されている。

企業管理者向けの機能とAPI

Enterprise/Business管理者がよく使う機能とAPIは次のとおりである。

  • コンテンツ除外（Content Exclusion） ―― 特定のリポジトリ・パスをCopilotの提案対象から除外する。ただし「Copilot CLIと、IDE内のCopilot ChatのAgent Modeはコンテンツ除外に対応しない」という制約がある点に注意
  • 利用状況メトリクスAPI ―― 組織・エンタープライズ単位の利用状況を取得するAPI。日次・28日次のレポートをダウンロードリンク形式で取得する
GET /enterprises/{enterprise}/copilot/metrics/reports/enterprise-1-day
GET /enterprises/{enterprise}/copilot/metrics/reports/enterprise-28-day/latest
GET /enterprises/{enterprise}/copilot/metrics/reports/repos-1-day
GET /enterprises/{enterprise}/copilot/metrics/reports/user-teams-1-day
GET /enterprises/{enterprise}/copilot/metrics/reports/users-1-day

利用には、エンタープライズの「Copilot usage metrics」ポリシーを「Enabled everywhere」にしておく必要がある。Organizationレベルにも同様のエンドポイントが用意されている。

  • 課金利用状況API ―― GET /organizations/{org}/settings/billing/ai_credit/usage などで、AI Creditsの消費状況を取得できる
  • 監査ログAPI ―― GET /orgs/{org}/audit-log で組織の監査ログを取得する。2026年からは「エージェント専用の監査ログ項目」が追加され、actor_is_agentやagent_session_idといったフィールドで、人間が始めたタスクかエージェントが自律的に行った操作かを区別できるようになった
  • 参考ダッシュボード ―― github-copilot-resources/copilot-metrics-viewer（MIT）は、GitHub自身が開発したものではないが、GitHubからもリンクされる代表的なオープンソースの可視化ダッシュボードである

企業で導入する場合、まずOrganization custom instructionsで全社共通ルールを定義し、各リポジトリのAGENTS.md／.github/copilot-instructions.mdでプロジェクト固有のルールを補い、利用状況メトリクスAPIで定着度を追う、という3段構えが実務的である。

3.4 RAG（検索拡張生成）

RAGとは何か。 RAG（Retrieval-Augmented Generation）は、質問に関連する外部の文書やデータをその場で検索し、LLMのコンテキストウィンドウに注入してから回答させる手法である。モデルが学習時点で知らない情報や、社内限定の情報についても、幻覚を抑えながら回答できるようになる。

代表的なOSSフレームワーク

  • LangChain ―― 現在は自らを「エージェント・エンジニアリングのプラットフォーム」と位置づけており、純粋なRAGフレームワークという枠を超えている。LangGraph・LangSmith・Deep Agentsとセットで語られることが多い（詳しくはPart 4.4）
  • LlamaIndex ―― RAG用フレームワークとして広く使われてきたが、近年は文書解析・抽出に特化した「LlamaParse」へのビジネス面での比重が増している
  • ベクトルデータベース ―― Chroma（Apache-2.0）、Qdrant（Apache-2.0、Rust製）、Weaviate（ベクトル検索＋キーワード検索＋リランキングを統合）、Milvus（大規模・Kubernetesネイティブ）、pgvector（PostgreSQLの拡張として利用）
  • リランキング ―― 一次検索の結果をCross-EncoderやLLMで並べ替え、関連度の高い順に並べ直す技術。WeaviateやQdrantは標準機能として組み込んでいる

エージェンティックRAGとMCP

近年は、RAGを「LLMの前段に固定的に挟むパイプライン」としてではなく、「エージェントが必要なときに自分で呼び出すツールの一つ」として設計するエージェンティックRAGという考え方が広がっている。これはまさにMCPが解決しようとしている領域であり、検索エンジンやベクトルDBをMCPサーバーとして公開すれば、どのエージェントからも同じ手順で呼び出せるようになる。

コンテキストウィンドウが大きくなるとRAGは不要になるのか

これはよく議論されるテーマである。実際、GraphRAG（Microsoft）のように、一時期注目された手法が「フロンティアモデルの能力がここ数年で大きく変わったため」という理由でメンテナンスモードに入った例もある。とはいえ、「検索して渡す」という発想自体がなくなるわけではなく、コードベースについては後述のCodeGraphのような「構造化された検索（グラフ）」に重心が移りつつある、と捉えるのが実情に近い。

Part 4. 実践のためのOSSツール箱

ここでは、「今日から試せる」オープンソースツールを、目的別に整理する。

4.1 設計・仕様駆動開発を支えるツール

「エージェントに実装させる前に、設計をどう固めるか」という課題に対して、近年いくつものOSSが登場している。

  • GitHub Spec Kit（github/spec-kit）―― GitHub公式の仕様駆動開発（Spec-Driven Development）ツールキット。仕様書を起点に、計画・実装・検証まで一連のプロセスをスラッシュコマンドで進める。バグ修正用・アイデア検証用のワークフローも用意されている
  • BMAD-METHOD（bmad-code-org/BMAD-METHOD）―― 「Agile Ai Driven Development」を掲げるOSS。「Clarify（明確化）→ Plan（計画）→ Build and verify（構築と検証）→ Learn and adjust（学習と調整）」というループを、小さな変更から長期間保守するシステムまで同じ方法でカバーする
  • OpenSpec（Fission-AI/OpenSpec）―― Spec Kitより軽量で、特定のIDEに縛られないことを志向するMITライセンスのツール
  • Kiro（AWS）―― Specs・Steering・Hooks・MCP対応などを備えるAWSのエージェント型IDE。コア製品自体はクローズドソースだが、周辺コンポーネント（KiroCrewなど）の一部がOSSとして公開されている

いずれも解決しようとしている問題は共通している。**「エージェントが合意された設計から逸れて、その場しのぎのコードを書いてしまう」**ことを防ぐ、という点である。

4.2 エージェントのルール・ガードレール標準

「どのファイルを置けば、どのツールがルールとして読んでくれるか」を一覧にする。

ファイル／仕組み 読み込むツール 備考
AGENTS.md ベンダー中立のオープン標準。GitHub Copilotも対応 迷ったらまずこれ
CLAUDE.md Claude Code（GitHub Copilotも対応） Claude系での事実上の標準
GEMINI.md Gemini CLI / Code Assist（GitHub Copilotも対応） Gemini系での事実上の標準
.cursor/rules/*.mdc Cursor description/globs/alwaysApplyのfrontmatterを持つ。旧.cursorrulesの後継
.clinerules（および.clinerules/hooks/） Cline（CLI・VS Code拡張・JetBrainsプラグイン） 「コーディング規約・アーキテクチャ方針・デプロイ手順・テスト要件」を書く運用が公式に案内されている
.continue/rules/*.md Continue.dev name/globs/regex/description/alwaysApplyを持つMarkdown。辞書順に読み込まれる

実務上は、AGENTS.mdを正本にしつつ、各ツール固有のファイルは「AGENTS.mdを参照してください」という1行だけにする運用が、重複を避けるうえで有効である。

4.3 トークン・コンテキスト節約ツール

エージェントが「賢いかどうか」と同じくらい、「必要な情報だけを、必要なタイミングで渡せているか」が、速度とコストを左右する。

  • repomix（yamadashy/repomix）―― リポジトリ全体を、AIが読みやすい1つのファイル（XML/Markdown/JSON）にパッケージ化する。Tree-sitterを使った--compressオプションで、シグネチャだけを残すような圧縮も可能。MCPサーバーとしても提供されている

  • LLMLingua / LLMLingua-2（microsoft/LLMLingua）―― プロンプト自体を最大20倍程度まで圧縮する技術。LangChainやLlamaIndexのRAGパイプラインとも統合できる

  • ast-grep（Rust製）／Universal Ctags ―― 抽象構文木（AST）やシンボル単位でコードを検索・書き換えるCLI。grepより正確にコード構造を扱える

  • プロンプトキャッシュ ―― Anthropic・OpenAI・Geminiはいずれもプロンプトキャッシュ機能を提供しており、同じシステムプロンプトやドキュメントを使い回す場合のコストを大きく下げられる

  • CodeGraph（colbymchenry/codegraph、MITライセンス）―― 「AIコーディングエージェントに、外科手術のように的確なコンテキストを与え、ツール呼び出しの回数を減らし、応答を速くする」ことをうたう、完全ローカル動作のツール。Tree-sitterで30以上の言語を解析し、シンボル・呼び出し関係・依存関係をコード知識グラフとして事前に構築しておく。エージェントは「このコードを理解するために、grep→glob→readを何度も繰り返す」代わりに、一度の問い合わせで、関係する呼び出しパス込みの的確なコードを受け取れる。Claude Code、Cursor、Codex CLI、Gemini CLI、GitHub Copilot（VS Code・CLI・JetBrains）など主要なエージェントにMCPサーバーとして自動設定でき、ファイル変更を監視して差分だけをグラフに反映する自動同期機能も備える

    本文の執筆者自身が、このCodeGraphを自分のPCに導入していたことが、今回この節を書くきっかけになった。「コードベースの構造を事前にグラフ化しておき、エージェントには毎回grepさせない」という発想は、Part 2で述べた「同じ資料を毎回貼り直さない」という原則の、コード版だと言える。

4.4 マルチエージェント・オーケストレーションフレームワーク

複数のエージェントやステップを組み合わせて複雑なワークフローを作りたいとき、以下のフレームワークがよく使われる。

  • LangGraph（langchain-ai/langgraph、MIT）―― エージェントの制御フローを「グラフ（状態機械）」として表現する低レベルのオーケストレーションフレームワーク。処理単位をノード、制御フローをノード間のエッジとして定義し、状態をグラフ全体で共有する。チェックポイント機能により障害からの再開や長時間実行に強く、**人間の承認待ち（human-in-the-loop）**をグラフの途中に組み込める点が、単純な直線的処理（chain）との大きな違いである。単なるchainは一度きりの直線的な実行しかできないのに対し、LangGraphはループ・分岐・再開可能な状態を扱える。LangChainの上位パッケージ「Deep Agents」（計画・サブエージェント・ファイルシステム操作を備える）はLangGraphの上に構築された、より高水準な抽象化である。可視化・プロトタイピングのためのStudio環境（LangSmith Studio）も提供されている
  • CrewAI（crewAIInc/crewAI）―― 役割（Crew）を軸にしたマルチエージェント・オーケストレーションフレームワーク
  • AutoGen → AG2（ag2ai/ag2）―― MicrosoftのAutoGenは後継のAG2に引き継がれ、APIが刷新された（旧APIは「AG2 Classic」として別リポジトリに保存されている）
  • OpenAI Agents SDK（openai/openai-agents-python）―― プロバイダー非依存。Agent・Sandbox agent・Realtime agent・Voice agent・Handoff・Guardrails・Tracingといった機能群を持つ
  • Microsoft Agent Framework（microsoft/agent-framework）―― Semantic KernelとAutoGenの両方の後継として統合された新フレームワーク
  • Google ADK（Agent Development Kit、google/adk-python）―― コードファーストで、Python/Java/Kotlin/Go/TypeScriptに対応。Geminiに最適化されているが、特定モデルに縛られない

4.5 可観測性・評価・ガードレール

エージェントを「作って終わり」にしないためには、動かした後の観測と評価が欠かせない。

  • LangSmith ―― トレーシング・可観測性・評価を統合したプラットフォーム。OpenAI、Anthropic、CrewAIなど主要フレームワークと連携する
  • Langfuse（langfuse/langfuse）―― 「オープンソースのLLMエンジニアリングプラットフォーム」。開発・監視・評価・デバッグを一貫して行える
  • Arize Phoenix（Arize-ai/phoenix）―― OpenTelemetryを基盤にしたオープンソースのAI可観測性プラットフォーム。OpenAI Agents SDK、Claude、LangGraph、CrewAI、Google ADKなど幅広く対応
  • OpenTelemetry GenAI Semantic Conventions ―― GenAIクライアントやMCPのための共通の計装（instrumentation）規約。「エージェントの可観測性」自体が標準化されつつあることを示している
  • Guardrails AI（guardrails-ai/guardrails）―― 入出力に対するガード（Input/Output Guards）を定義できるPythonフレームワーク。「Guardrails Hub」という検証ルールのマーケットプレイスを持つ
  • NVIDIA NeMo Guardrails（NVIDIA/NeMo-Guardrails）―― 会話の話題・進行・文体などをプログラム的に制御できるガードレールツールキット
  • OWASP Top 10 for LLM Applications（genai.owasp.org）―― プロンプトインジェクション、不適切な出力処理、機密情報の漏洩など、LLMアプリケーション特有のリスクを整理した業界標準のチェックリスト。GenAI Security Projectとして継続更新されている

4.6 コンピュータ操作・ブラウザ操作・評価ベンチマーク

  • Anthropic Computer Use ―― 画面のスクリーンショットを見ながらマウス・キーボード操作を行うエージェントのリファレンス実装
  • Playwright MCP（microsoft/playwright-mcp）―― アクセシビリティツリーを使った（＝ピクセルではなく構造を見た）ブラウザ自動操作のMCPサーバー
  • browser-use（browser-use/browser-use、MIT）―― オープンソースのブラウザ操作エージェント
  • A2A Protocol（Agent2Agent、a2aproject/A2A）―― エージェント同士が互いの能力を宣言し合い、連携するためのプロトコル。元々はGoogleが提唱したが、現在はLinux Foundation傘下のオープンソースプロジェクトとして運営されている
  • 評価ベンチマーク ―― コーディングエージェントの実力を測る代表例がSWE-bench（実際のGitHub issueを解けるかを測る。Verified版やMultimodal版など複数のバリエーションがある）と、ツール利用・対話能力を測るτ-bench系ベンチマークである

4.7 データサイエンス・MLOps定番のOSSツール

コーディングエージェントだけでなく、データサイエンス・機械学習の現場を支える定番OSSも押さえておきたい（詳しい使い方はPart 5.3で扱う）。

カテゴリ 代表的なツール
実験管理・モデルレジストリ MLflow（Apache-2.0）、Aim（Apache-2.0）、Weights & Biases（SDKはMIT、本体はホスト型）
データ・パイプラインのバージョン管理 DVC（Apache-2.0、"Git for Data"）、lakeFS（BUSL-1.1）
ワークフローオーケストレーション Apache Airflow、Prefect、Dagster、Kedro（Linux Foundation配下）、ZenML（エージェント連携も統合）
特徴量ストア Feast（Apache-2.0）
データ品質・検証 Great Expectations（Apache-2.0）、Pandera（MIT、Union.ai管理）
本番監視 Evidently AI（Apache-2.0）、Arize Phoenix
ハイパーパラメータ探索 Optuna（MIT、Preferred Networks開発）、Ray Tune（Apache-2.0）
モデル配信 BentoML、Ray Serve、vLLM（PagedAttentionで有名）、NVIDIA Triton Inference Server
分散学習・ファインチューニング Hugging Face（Transformers/Datasets/Accelerate/PEFT）、DeepSpeed、Axolotl、LlamaFactory、Unsloth
ノートブック・DataFrame JupyterLab、Marimo（リアクティブ・Gitフレンドリーなノートブック）、Polars（Rust製の高速DataFrame）

4.8 Karpathyに学ぶ「最小の教育的リポジトリ」系譜

著名な研究者であるAndrej Karpathy（元Tesla AI責任者、OpenAI共同創業メンバーの一人）は、一貫して「最小限のコードで本質を学ぶ」というスタイルのリポジトリを公開し続けている。

micrograd（~100行の自動微分エンジン）
  └─ nanoGPT（GPT-2クラスの学習・ファインチューニング。現在は後継に道を譲り非推奨）
       └─ llm.c（PyTorchを使わない、C/CUDAだけのLLM学習実装）
            └─ nanochat（トークナイザ学習から推論までフルスタックの、単一GPUノード向け最小ChatGPTクローン）
                 └─ autoresearch（AIエージェントに、nanochatベースの学習コードを一晩中自律改善させる実験）

特にautoresearchは、本文の主張を別の角度から裏付けている。人間が書くのは、エージェントへの指示をまとめたprogram.mdというMarkdownファイルだけであり、Karpathy自身がこれを「軽量なskill」と表現している。エージェントは固定5分間の学習を繰り返し、val_bpbという指標で改善を判定しながら、一晩で100回前後の実験を自律的に回す。「エージェントに何を・どう指示するかをファイルとして設計する」という本文全体のテーマが、研究の最前線でも同じ形で現れている好例である。

Part 5. 職種・用途別の活用パターン

ここまでの原則（4分類モデル・アクセス方法・MCP/RAG・OSSツール）は共通の土台だが、実際にどう使うかは職種によって大きく変わる。

5.1 一般のビジネス職（総務・人事・マーケティング・法務・財務など）

コーディングエージェントほど複雑なセットアップは不要だが、同じ原則が有効である。

  • AGENTS.mdに相当するもの ―― 「社内文書は丁寧語で」「金額は税込で明記」「契約書の表現は変更しない」といった、部署として常に守るルールを、Custom GPTs／Claude Projects／Gemini Gemsなどの説明欄に書いておく
  • SKILLに相当するもの ―― 「契約書レビューの観点」「月次レポートの構成」「問い合わせ対応のトーン」など、業務ごとの手順書を再利用可能な形で用意する
  • Docsに相当するもの ―― 社内規程、価格表、過去の契約書、ブランドガイドラインなどをConnector経由で参照させる
  • 向いている用途の例
    • 法務：契約書の論点整理、過去条項との差分比較（最終判断は必ず人間が行う）
    • マーケティング：競合調査の下書き、広告コピーのバリエーション作成
    • 人事：求人票のたたき台作成、面接質問リストの整理
    • 財務：経費精算の説明文の下書き、レポートの要約

注意点：これらの職種では、生成物をそのまま対外的に使う前に、必ず専門知識を持つ人間が確認する体制を前提にすべきである。

5.2 ソフトウェアエンジニア（コーディングエージェント）

本文のPart 2〜4が最も直接的に当てはまる領域である。改めて要点を一言でまとめると、

  • ルールはAGENTS.md（またはCLAUDE.md）に、手順はSKILLに、知識はDocsに、今回の指示だけをチャットに書く
  • CLIエージェントは並列に走らせられる。Claude Codeの開発者Boris Chernyは、2026年1月に公開したワークフローで次のような運用を共有している
    • 複数のgit worktreeでClaude Codeを5並列で走らせ、さらにWeb版でも5〜10セッションを並行させる
    • 重い作業は基本的にOpus系モデル＋thinking modeを使う。「誘導の手間が減り、ツール利用が上手になる分、結果的に小さいモデルより速く終わることが多い」という考え方である
    • チーム全員で1つのCLAUDE.mdをGitにコミットし、「Claudeが間違えた操作をするたびに追記する」。さらにPull Request上で@claudeにメンションし、Claude自身にCLAUDE.mdを更新させる運用まで行っており、これを「Compounding Engineering（複利的エンジニアリング）」と呼んでいる
    • 作業はまずPlan Mode（Shift+Tabを2回）で計画を練ってから、編集を自動承認するモードに切り替える
    • よく使うタスクは.claude/commands/のスラッシュコマンドやサブエージェント（build-validator、code-architectなど）としてチームに共有する
  • 同じBoris Chernyは、別の場面では「もうClaudeにプロンプトを打たない。Claudeにプロンプトを与え続けるループを走らせている。私の仕事はループを書くことだ」とも述べている。これはPart 1.6で紹介した**ループエンジニアリング（Loop Engineering）**そのものであり、「毎回指示する」から「指示し続ける仕組みを設計する」への移行が、トップクラスの実務者のあいだですでに起きていることを示している
  • 本番用コードに対する期待値は「人間が書いた場合と同等以上」であるべき、という考え方も広がっている
  • CodeGraph・repomixのようなツールで、エージェントに無駄なgrepを繰り返させない

5.3 データサイエンティスト・MLエンジニア

Claude Code、Gemini CLI、OpenAI Agentsなどを活用してデータ分析や機械学習開発を進める場合、AIエージェントを単なるチャットツールとして使うだけでは不十分である。AIエージェントを「再利用可能な開発環境」の一部として設計することが重要になる。

推奨するプロジェクト構成

project/
├─ AGENTS.md
├─ README.md
├─ pyproject.toml
│
├─ docs/
│   ├─ business.md
│   ├─ metrics.md
│   ├─ domain.md
│   ├─ data_dictionary.md
│   └─ decisions/
│
├─ data/
│   ├─ raw/
│   ├─ interim/
│   └─ processed/
│
├─ notebooks/
│   ├─ 01_eda.ipynb
│   ├─ 02_feature_engineering.ipynb
│   └─ 03_modeling.ipynb
│
├─ src/
│   ├─ data/
│   ├─ features/
│   ├─ models/
│   └─ evaluation/
│
├─ tests/
│
└─ skills/
    ├─ eda/
    ├─ feature-engineering/
    ├─ modeling/
    ├─ evaluation/
    └─ mlops/

データサイエンス向けAGENTS.mdの例

# Data Science Project Rules

## Language

- 説明とドキュメントは日本語で記述する
- コード上の名前は英語で統一する

## Environment

- Python 3.12以上を使用する
- パッケージと仮想環境はuvで管理する
- 依存関係を追加した場合はpyproject.tomlを更新する

## Data Processing

- 元データを直接変更しない
- rawデータはdata/rawに保存する
- 中間データはdata/interimに保存する
- 学習用データはdata/processedに保存する
- 大規模データではPolarsを優先的に検討する

## Modeling

- 最初に単純なベースラインを作成する
- 学習データと評価データを明確に分離する
- データリークを確認する
- 評価指標はdocs/metrics.mdを参照する
- 乱数シードを固定する
- 実験条件を記録する

## Code Quality

- 再利用する処理はnotebookではなくsrcに実装する
- 関数には型ヒントを付ける
- 主要なデータ変換にはテストを追加する
- 可読性と再現性を優先する

## Output

- 結論だけでなく根拠を示す
- 使用したデータ期間を明記する
- 制約、リスク、未検証事項を記載する

このように基本方針を定義しておけば、会話ごとに「まずベースラインを作ってください」「データリークを確認してください」と繰り返す必要が少なくなる。

機械学習業務をSKILLとして標準化する

機械学習プロジェクトでは、作業者によって分析手順や確認項目が変わりやすいという問題がある。そこで、代表的な作業をSKILLとして定義する。

EDA Skill

# EDA Skill

1. データ件数と期間を確認する
2. カラム名、型、意味を確認する
3. 欠損値を確認する
4. 重複データを確認する
5. 外れ値を確認する
6. 目的変数の分布を確認する
7. 説明変数との関係を確認する
8. 時系列変化を確認する
9. データリークの可能性を確認する
10. モデリングへの示唆を整理する

Feature Engineering Skill

# Feature Engineering Skill

1. 予測時点で利用可能な情報か確認する
2. 欠損値の意味を確認する
3. カテゴリ変数の処理方法を決める
4. 時系列特徴量の作成方法を検討する
5. 集約特徴量の計算範囲を確認する
6. データリークを確認する
7. 特徴量の業務的な解釈を記録する
8. 学習環境と推論環境で同じ処理を再現できるようにする

Modeling Skill（概要）

モデリングでは、アルゴリズムだけでなく、ビジネス課題から評価までを一つの流れとして整理する。

1. Business Problem      何を予測し、誰がどう使うのか、誤判定の損失は何か
2. Data Understanding    取得期間、粒度、欠損・偏り、学習時点と予測時点の差
3. Baseline              ルールベース、平均・中央値、ロジスティック回帰
4. Feature Engineering   業務知識由来の特徴量、集約・時系列・カテゴリ変数
5. Model Selection       精度、推論速度、説明可能性、運用コスト
6. Evaluation Metrics    Accuracy / Precision / Recall / F1 / ROC-AUC / PR-AUC / MAE / RMSE / 業務KPI
7. Error Analysis        False Positive/Negativeの特徴、セグメント別・時期別の性能変化
8. Risks & Limitations   データリーク、過学習、サンプリングバイアス、コンセプトドリフト、公平性
9. Deployment            バッチ/リアルタイム、推論頻度、レイテンシ要件、モニタリング、再学習条件
10. Next Actions         追加データ取得、特徴量改善、評価方法見直し、PoC、本番導入判断

Docsには業務知識と判断基準を蓄積する

機械学習プロジェクトでは、モデルの技術的な情報だけでなく、業務知識が非常に重要である。

# business.md — Business Context

## Background
現在の業務プロセスと課題を記載する。

## Users
予測結果を利用するユーザーを記載する。

## Decision
予測結果によって変わる意思決定を記載する。

## Constraints
コスト、時間、規制、説明責任などの制約を記載する。

# metrics.md — Evaluation Metrics

## Primary Metric
Recallを主要指標とする。

## Reason
見逃しによる業務損失が、誤検知の対応コストより大きいため。

## Secondary Metrics
- Precision / F1-score / PR-AUC / 推論時間

## Acceptance Criteria
- Recall: 0.85以上
- Precision: 0.60以上
- 推論時間: 1件あたり200ms未満

# data_dictionary.md — Data Dictionary

## customer_id
- Type: string / Description: 顧客を識別するID / Nullable: No

## transaction_amount
- Type: float / Description: 取引金額 / Unit: JPY / Nullable: Yes
- Missing Meaning: 取引情報を取得できなかった場合

このように業務知識をファイルとして管理すれば、AIに毎回説明し直す必要がなくなる。また、モデルの評価指標やデータの意味が明文化されるため、人間のメンバーにとっても有用である。

作業例

# EDAを依頼する場合
docs/business.mdとdocs/data_dictionary.mdを参照し、
data/raw/customer.csvに対してEDAを実施してください。

EDA Skillの手順に従い、特に以下を確認してください。
- 目的変数の不均衡
- 欠損値の業務的な意味
- 時系列リークの可能性
- モデリングで使用できないカラム

結果をdocs/eda_report.mdに保存してください。

# モデルを評価する場合
docs/metrics.mdを基準として、
models/baselineとmodels/lightgbmを比較してください。

Evaluation Skillに従い、全体評価だけでなく、
顧客セグメント別のRecallとPrecisionも確認してください。

最後に、本番導入可否と追加検証項目を整理してください。

データサイエンス・MLOpsの定番OSSツール一覧はPart 4.7を、Karpathyの最小教育リポジトリ系譜（autoresearchを含む）はPart 4.8を参照のこと。

5.4 クオンツトレーディング

AIエージェントは、自動発注システムそのものとしてではなく、リサーチ・検証・レポーティングの補助として使うのが現実的である。本番の自動売買に組み込む場合は、誤発注・過学習・レジーム変化によるリスクを、人間のレビューとサーキットブレーカーで必ず抑える必要がある。

代表的な戦略モデルの分類（エージェントに調査・バックテストコードを書かせる際の語彙として）

  • トレンドフォロー／モメンタム ―― 価格の方向性が続くことに賭ける。移動平均線のクロス、ブレイクアウトなど
  • 平均回帰（Mean Reversion） ―― 価格が平均から乖離したら戻ることに賭ける
  • 統計的裁定（Statistical Arbitrage） ―― 相関する銘柄間の価格差を利用する
  • マーケットメイキング／マイクロストラクチャー ―― 板情報や取引フローの偏りを利用する
  • ファクター投資／マルチファクターモデル ―― バリュー・モメンタム・クオリティなどの因子でポートフォリオを構築する
  • 機械学習ベースのアルファ探索 ―― 特徴量から将来リターンを予測するモデルを構築する（Part 5.3のModeling Skillがそのまま応用できる）

実世界のベンチマークとしての「World Cup Trading Championship」

1984年から続く、実資金口座でのリターン率を競う「World Cup Championship of Futures Trading（通称World Cup Trading Championship）」は、トレンドフォロー系トレーダーのLarry Williamsが1987年に驚異的なリターンで優勝したことで知られるなど、特定の戦略スタイルが実際にどこまで通用するかを示す、数少ない公開された実績データの一つである。AIエージェントに戦略を調査・要約させる際、「この戦略カテゴリは過去にどのような実績データがあるか」を調べさせる題材として参照できる（個別の数値は年によって大きく変動するため、エージェントに調べさせた結果は必ず一次資料で裏取りすること）。

よく使われるOSSツール

カテゴリ ツール
バックテスト・戦略開発 backtrader、vectorbt、Zipline Reloaded、QuantConnect LEAN
AI指向の定量投資プラットフォーム Qlib（microsoft/qlib）―― Microsoftが公開する、データ処理からモデル学習・ポートフォリオ構築・バックテストまでを一貫して扱うAI指向の定量投資プラットフォーム
テクニカル指標計算 TA-Lib

エージェント活用時の注意点（本文の原則の応用）

  • AGENTS.md相当のルールとして、「バックテストには必ずLook-ahead biasとサバイバーシップバイアスのチェックを含める」「取引コストとスリッページを必ず考慮する」を明文化する
  • SKILLとして「バックテスト手順」「リスク指標（最大ドローダウン、シャープレシオ、ソルティノレシオ）の算出手順」を標準化する
  • 実績やパフォーマンス数値をエージェントに生成させた場合、fabricationのリスクが特に高い領域であるため、数値の出典を必ず明示させ、人間が再計算で検証する

Part 6. 導入ロードマップ

最初から完璧な構成を作る必要はない。まずは小さく始めるのが現実的である。

Step 1：繰り返している指示を見つける

過去のチャットを確認し、何度も入力している内容を探す。

例：日本語で回答してください／Pythonを使用してください／テストを追加してください／データリークを確認してください

常に必要な内容であれば、AGENTS.mdへの移動を検討する。

Step 2：繰り返している作業手順を見つける

何度も依頼している作業を整理する。

例：EDA／コードレビュー／モデル評価／README作成

再利用する可能性が高い作業は、SKILLとして標準化する。

Step 3：会話にしか存在しない知識をファイル化する

重要な業務知識や判断を、Docsへ移す。

例：KPIの定義／データの意味／モデル選定理由／業務上の制約／失敗した実験とその理由

Step 4：チャットを短くする

チャットでは、次の4点を中心に指定する。

1. 対象
2. 実行する作業
3. 参照する資料・SKILL
4. 期待する成果物

Step 5：接続とアクセス方法を整える

MCPサーバーやCodeGraphのような補助ツールを導入し、エージェントが「毎回同じ調べ方を繰り返す」状態から抜け出せるようにする。企業であれば、このタイミングでOrganization custom instructionsや利用状況メトリクスAPIも整備する。

Step 6：定期的に整理する

情報の役割は、プロジェクトの進行によって変化する。たとえば、最初は一時的なチャット指示だった内容が、何度も使われるようになれば、SKILLやAGENTS.mdへ昇格させるべきである。逆に、使われなくなったルールは削除する。

まとめ：本質的な学び

多くの人は、チャットの中に知識を蓄積しようとする。しかし、チャットは時間とともに長くなり、情報の所在や最新版が分かりにくくなる。重要な知識をチャット履歴だけに依存すると、再利用性や再現性も低くなる。

本来、チャットは次の役割を持つ場所である。

チャットはタスクを実行する場所であり、知識を保存する場所ではない。

長期的な知識は、AGENTS.md、SKILL、Docsへ蓄積する。チャットには、現在の課題と期待する成果物だけを記載する。

ルール → AGENTS.md
手順   → SKILL
知識   → Docs / Files
作業   → Chat

この構造に、Part 3〜4で見たMCP・RAG・各種OSSツールを組み合わせることで、次の改善が期待できる。

  • AIエージェントへの指示が安定する
  • 同じ説明の繰り返しを減らせる
  • 知識をプロジェクト資産として残せる
  • 他のメンバーが作業を再現できる
  • AIエージェントやベンダーを変更しても知識を引き継ぎやすい（AGENTS.mdやMCPのようなオープン標準を使っていればなおさらである）
  • データ分析やモデル開発の再現性が高まる
  • プロジェクトの保守性が向上する
  • 企業として利用状況を可視化し、ガバナンスを効かせられる

AI Agent時代に必要なのは、優れたプロンプトを一度書くことだけではない。ルール、手順、知識、タスクを分離し、適切なツールで接続し、継続的に改善できる情報構造を作ることである。この営みは「コンテキストエンジニアリング」と呼ばれることもあれば、Part 1.6で見た「ループエンジニアリング」、あるいは単に「エージェントの設定」と呼ばれることもある――呼び名が何であれ、やるべきことの本質は変わらない。

AIを単なるチャット相手ではなく、プロジェクトの開発環境の一部として設計する。この考え方が、ビジネス全般、ソフトウェア開発、データサイエンス、機械学習開発、そして定量分析に至るまで、これからのあらゆる職種に必要なスキルになると考えている。

最後に、本文の要点をまとめる。

  • プロジェクト全体の共通ルールはAGENTS.mdに置く（他ツールのCLAUDE.md/GEMINI.mdはそれを参照させる）
  • 特定作業の手順はSKILLとして分離する（Agent Skills標準のSKILL.mdを活用する）
  • 業務知識や仕様はDocs／Filesとして保存する
  • チャットには現在実行するタスクだけを書く
  • 同じ資料を何度も貼り直さない
  • ツール接続にはMCPを、外部知識の参照にはRAGを使い、両者は組み合わせて使える
  • CodeGraphやrepomixのようなツールで、エージェントに無駄な探索を繰り返させない
  • 設計駆動開発ツール（Spec Kit、BMAD-METHOD）で、エージェントが設計から逸れないようにする
  • 慣れてきたら「毎回指示する」から「指示し続ける仕組み（ループ）を設計する」段階への移行も検討する（Part 1.6）
  • 企業導入では、Organization custom instructionsと利用状況メトリクスAPIでガバナンスと可視化を両立させる
  • 職種によって使い方は変わるが、「ルール・手順・知識・タスクを分ける」という原則は共通している
  • 情報の正本を一つに決め、他の場所から参照する

チャットを知識庫にしない。AIエージェントが再利用できる形で、知識をプロジェクトに残す。

参考リンク集

本文で紹介したツール・標準・資料の公式リンクをまとめる（いずれも執筆時点のURL）。

基礎・カリキュラム

標準・プロトコル

設計駆動開発

トークン節約・コード理解

オーケストレーション・観測性・ガードレール

各社エージェント

データサイエンス・クオンツ

1
0
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
Sign upLogin
1
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?