a-partical-guide-to-building-agentsとこれまでのナレッジを統合する
ひとまずNotebookLMが出してくれたテキストをベタ張りしておく。
追記:
CI/CD環境とか自動テストはどうやって構築するんだろ
「a-practical-guide-to-building-agents.pdf」を読むと、AIエージェントというものが、単にLLMを組み込んだチャットボットなどとは異なり、ユーザーに代わってタスクを自律的に完遂できるシステムだと定義されていますね。ワークフローを実行し、意思決定を行い、必要に応じて自身の行動を修正したり、失敗時には制御を人間に戻したりできる、と。そして、外部システムと連携するための「ツール」にアクセスし、状況に応じて適切なツールを動的に選択する、と説明されています。
このガイドで示されているエージェントのコアコンポーネントはシンプルですね。「モデル（LLM）」、「ツール」、「指示」の3つだと。
モデル: エージェントの推論と意思決定の動力源となるLLMですね。タスクに応じて最適なモデルを選ぶ試行錯誤が重要そうです。
ツール: エージェントが外部システム（APIやUIなど）と連携して、情報を収集したり、行動を起こしたりするための機能ですね。データ取得、アクション実行、さらには他のエージェントをツールとして使うこともできるようです。ツールの数が増えたり、ロジックが複雑になったりすると、複数のエージェントに分割することを検討する、ともありますね。
指示: エージェントがどのように振る舞うかを定義するガイドラインで、これがエージェントの意思決定の質に不可欠だ、と。既存の業務マニュアルなどを活用し、タスクを細分化し、明確なアクションを定義し、エッジケースへの対処法を記述することが重要だ、と書かれています。
さて、この「指示」の重要性という点は、文脈知識 の話と深く繋がるように感じます。CSエージェントの例で言及されているように、エージェントが顧客の状況や要求、そしてそれにどう対処すべきかを判断するためには、単なるマニュアル知識だけでなく、「なぜそのような判断が必要か」「目指すべきビジネスゴールは何か」といった意味の構造や、顧客の利用状況といった関係の構造、つまり「文脈知識」が必要になる、と。この文脈知識は、往々にして業務担当者の暗黙知になっていることが多い。
この暗黙知である「文脈知識」を形式知化し、エージェントの判断基準（つまり「指示」やそれに関連する知識ベース）として活用する手段として、モデリングが有効ではないか、という話がありました。業務の全体像や各ステップの「なぜ？」をモデリングで可視化し、チーム全体（エンジニアと業務担当者）で共通認識としてオーソライズしていく。そして、その過程で得られた意味の構造をプロンプト化するなどしてエージェントにインプットすることで、不確実性を減らせる可能性がある、と。これは、「a-practical-guide」でいうところの、高品質な指示を定義し、エッジケースに対処するための重要なプロセスと言えるでしょう。
次に、開発の進め方について見てみましょう。「a-practical-guide」では、最初から複雑な自律エージェントを目指すのではなく、インクリメンタルなアプローチが成功しやすいと推奨されています。まずは単一エージェントでツールの追加などから始め、複雑性が増したらマルチエージェントシステムへ移行する、と。オーケストレーションパターンとして、マネージャーパターン（中心エージェントが他のエージェントをツールとして使う）や分散パターン（エージェント同士がタスクをハンドオフする）が紹介されています。
これは、AI-Agent開発進め方比較をDeepResearchした結果に挙げられている開発手法と共通する視点があるように思えます。リーン・アジャイル型は、最小限のプロトタイプ（MVP）で高速に開発し、仮説検証サイクルを速く回す。段階的拡大型は、PoCで検証した知見を本格運用に移行するプロセスを重視する。どちらも、小さく始めて検証し、そこから学びながら進めるという点で、「a-practical-guide」のインクリメンタルなアプローチと方向性が一致していますね。Algomatic社の「UIも自動化も後回し」で、まずAIの価値検証にフォーカスし、スプレッドシートや簡易ツールで高速に試行錯誤を繰り返すアプローチ は、まさにこの考え方を体現していると言えるでしょう。 フェーズ0（準備と課題探索）で、業務の深い理解やAI適用候補の絞り込み、PoCスコープの初期仮説立てを行う。
フェーズ1（価値検証と高速プロトタイピング）で、「5-10個のApp」やMVAを作り、AIの能力やユーザーの反応を観察し、価値を検証する。ここでは、とにかく素早く動くものを作ることに注力し、洗練されたアーキテクチャは後回しにする、と。
フェーズ2（構造化と洗練）で、価値が見えたら、そこで得られた知見を基にドメインモデルやアーキテクチャをちゃんと設計していく、と。
これは、「AI自体の能力の不確実性や、それが現場業務にどのようなインパクトを与えるかが未知数」であるAIエージェント開発においては、詳細な事前設計よりも「小さく動くものを作り、現場で試して、そこから学ぶ」という経験主義的なアプローチが適している、という考えに基づいています。これは、野中郁次郎氏の「野性」の概念（経験主義）にも通じるところがありそうです。
そして、この開発プロセス全体において、エンジニアの役割も変化しますね。もはや言われた通りのコーディングをするだけでは、24時間文句も言わず指示を実行するAIと競合することになってしまうかもしれない。エンジニアリングの本質は技術ではなく、技術を価値提供に応用すること。問題領域を分析し、最適な解を提供する。そして、価値提供に伴う「偶有的な複雑性」を隠蔽する役割を担う。
AIエージェントが偶有的複雑性の大部分を担うようになった時代でも、エンジニアには「本質的な複雑性」に向き合うことが求められます。つまり、問題領域を理解し、システム全体を構成する部品（モジュール）を明らかにし、AIに任せられる単位に細分化する、「ちゃんと設計する」能力ですね。これは、DDDでいうドメインモデルの構築や境界づけられたコンテキストの特定、そしてモジュール分割といった、システムを構造化・抽象化する能力に他ならない、と。AIは固有の文脈を知らないため、エンジニアが文脈を与え、タスクを適切に切り出してあげる必要がある、という経験則も示唆されていますね。
さらに、「a-practical-guide」では、エージェントが安全かつ予測可能に動作するために、ガードレール（関連性チェック、安全性のフィルタリング、PIIフィルタリングなど）や人間による介入の仕組みが非常に重要だと強調されています。特に開発初期段階では、人間が介入することで失敗を特定し、エッジケースを発見し、エージェントの性能向上に繋げることができる、と。タスクを完遂できない場合に人間へ制御を渡す、というのは、まさにAI-Humanインターフェースの設計そのものですね。
まとめると、AIエージェント開発は、
1. まずエージェントのコアコンポーネント（モデル、ツール、指示）を理解することから始まる。
2. 開発アプローチとしては、AIの能力や業務への影響が未知数であるという不確実性ゆえに、小さく始めて価値を検証するインクリメンタルかつ実験的な手法（リーン、PoC、高速プロトタイピング）が効果的である。
3. 価値が見えてきたら、モデリングなどの手法を活用して業務やシステムの「意味の構造」を深く理解し、それを基にシステム全体を構造化・洗練させていくフェーズに進む。この構造化能力こそ、AI時代にエンジニアに求められる本質的なスキルだ、と。
4. エージェントが効果的に機能するためには、暗黙知を含む「文脈知識」を形式知化し、「指示」として与えるプロセスが不可欠であり、そのためにモデリングなどが役立つ。
5. そして、現実世界での運用には、ガードレールによる安全性確保と、AIが対応できないケースを想定した人間による介入の設計が極めて重要となる。
このように見てくると、AIエージェント開発における工程は、従来のシステム開発の要素（問題分析、設計、実装、テスト）を含みつつも、「AIの能力検証」と「人間との協調（AI-Humanインターフェース、文脈知識の共有）」、そして「安全性の担保」といった側面に強くフォーカスしている、と言えそうです。
AIエージェントが担う範囲が広がるにつれて、エンジニアはますますシステム全体、特に人間とAIの境界領域や、AIに的確な指示とコンテキストを与えるための「問題領域の構造化」に注力していく、ってことでしょうか。
このAI-Agent開発のアプローチについて、皆さんの経験や他の事例と照らし合わせて、さらに深掘りできる点は何かあるでしょうか？ 特に、「価値探索」と「構造化」のバランスをどう取るべきか、といったあたりは議論の余地がありそうですね。