Agent Infrastructure

AIエージェント導入は、
ツール選定より
評価と文脈設計から始める

AIエージェントのニュースは、ツール名やフレームワーク名で語られやすい。しかし実務に入れると、成果を分けるのはモデルやUIだけではない。何を読ませ、何を成功とし、どの失敗を許さないか。エージェント導入の本体は、評価と文脈の設計である。

Section 01 — ツール導入の罠

ツールを増やすだけでは、エージェントは仕事を覚えない

GitHubには、コード理解、長期実行エージェント、複数人格エージェント、コンテキスト統合、プロンプト改善のためのOSSが次々に出ている。それぞれ有用である一方、導入すればすぐに業務品質が上がるわけではない。エージェントは、接続されたデータ、与えられたルール、評価される基準に強く依存する。

Tool First

ツール先行

OSSから試す
業務を丸投げする
感覚で評価する
プロンプトだけ直す

System First
評価先行入出力を決める
文脈を整える
合格条件を書く
ログを運用に戻す

エージェントに仕事を任せるとは、AIに自由を与えることではなく、文脈、権限、評価を設計することである。

Section 02 — 文脈設計

エージェントの精度は、モデルよりも「アクセスできる文脈」で決まる場面が多い

複数データソースを横断して文脈を作る動きは、エージェント導入の実務課題をよく表している。社内DB、API、ドキュメント、GitHub、Notion、CRMが分断されたままでは、AIは一般論に寄る。文脈がつながるほど、回答は業務固有の判断に近づく。

静的ルールを読ませるCLAUDE.md、AGENTS.md、設計方針、運用ルールのような「判断の前提」を置く。

現在の状態を読ませるIssue、PR、顧客情報、在庫、計測値、最新ドキュメントなど、今の判断に必要な状態を接続する。

過去の判断を読ませるなぜその設計にしたか、過去に何が失敗したか、どの基準を優先したかを残す。

Section 03 — 評価のボトルネック

エージェント開発のボトルネックは、生成ではなく評価になる

AIが出力を作る速度は上がっている。その結果、人間側で重くなるのは、出力が正しいか、使えるか、危険ではないかを判定する工程である。評価を手作業に残したままエージェントを増やすと、開発速度は途中で止まる。

What To Evaluate

評価すべきもの

事実の正確性
依頼範囲の遵守
既存ルールとの整合
安全な権限利用
成果物としての完成度

How To Evaluate

評価の置き方

チェックリストを明文化する
失敗例をテストケースにする
人間レビューを最後だけに置かない
自動評価と手動評価を分ける
評価結果を次回の文脈に戻す

Section 04 — 役割分担

複数エージェントは、人数を増やす話ではなく、役割と責任を分ける話である

複数人格エージェントやエージェントチームの発想は、人間の組織構造に近い。ただし、役割を増やすだけでは混乱する。調査、実装、レビュー、品質保証、運用の責任を分け、誰が何を判断しないかまで決める必要がある。

Role 1

Explorerコード、資料、データから必要な事実を探す。判断よりも確認に責任を持つ。

Role 2

Worker決められた範囲を実装する。勝手な拡張ではなく、依頼範囲と既存ルールに責任を持つ。

Role 3

Reviewer成果物を使う前に、失敗条件、差分、未確認事項を見る。最後の安全弁として置く。

AIエージェントを増やすほど、
人間の仕事は消えるのではない。
評価基準と文脈を設計する仕事へ寄っていく。

References — 参考・引用元

この記事で参照した元ネタ

以下の元ネタをもとに、AIエージェント導入基盤の実務視点として統合・再構成した。

AI評価が新しい計算ボトルネック化
Hugging Face
Claude コーディング能力を高める CLAUDE.md
GitHub
https://github.com/forrestchang/andrej-karpathy-skills
Agency Agents：複数人格エージェントフレームワーク
GitHub
https://github.com/msitarzewski/agency-agents
複数データソースを横断するエージェント文脈化 / GitNexus / PostHog
CSV収集行を統合

AIエージェント導入は、ツール選定より評価と文脈設計から始める