現場で活用するためのAIエージェント実践入門【読書ログ】

気になったところをメモしながら読んでいる。
第一部読み終わった。いまのところ超良書。めっちゃ自分に刺さってる。
引き続き期待！

第Ⅰ部 AIエージェントを知る

第1章 AIエージェントの概要

1.1 AIエージェントとは？

1.1.1 AIエージェントの定義

• ユーザ、AIエージェント、環境（Python実行環境、アプリ等）をシーケンス図で表現するのいいな。取り入れていこう
• エージェントの行動範囲を「環境」って呼ぶのって一般的なのかな。自分の周りでは聞いたことないけど
  • 「環境」ってだいぶ多義語だからあまり使われないのかも？

1.1.2 AIエージェントが持つ特性

1.2 AIエージェントのビジネス状況

1.2.1 AIエージェントのビジネスの流れ

• いろんなAIエージェント紹介してるけどClaude Codeがなかった。開発者特化すぎると判断されたのかな。間に合わなかったのかな

1.2.2 AIエージェントの活用例

1.3 AIエージェントの技術的な位置づけ

1.3.1 エージェントの作り方は学習か、推論かcolumn エージェント学習（Agent-Tuning）

• AIエージェントの作り方は学習と推論の2パターン
  • 推論パターンがよくやる方。プロンプトとかワークフローを組んでLLMを動かすやり方。DifyとかLangGraphとか
  • 学習パターンは、事後学習でエージェントを作るやり方。タスク特化型ではあるが、推論パターンよりも精度が出やすいらしい
    • エージェント学習（Agent-Tuning）: AIエージェントの性能を特定のタスクや環境に最適化する手法。特にオープンソースのLLMの能力を向上させるための研究分野として注目されている
      • エージェント学習のポイントは、軌跡データの作成
        • 軌跡データ: AIエージェントの問題解決までの思考、行動、観察の組みで表現。これを学習データとしLLMを事後学習する
        • コストがネック
  • 特化型の方作ったことないなあ。やってみたいけど、そんな計算リソースはないし案件もない。。。

1.3.2 LLMからAIエージェントまでの階段

1.4 AIエージェント開発の選択肢

1.4.1 エージェント構築フレームワーク

1.4.2 構築フレームワークを使う懸念

• AIエージェント系フレームワークを使う際の考え方めっちゃ同意
  • プロトタイプ開発にはいいけど、プロダクトにするときは慎重にという考え方
  • プロンプトの内容が意図せず変わったりツール実行タイミングが制御しづらいとか観測しづらいとか、そういう観点
  • まじでそうofそう

1.5 まとめ

• Agentic WorkflowsってAndrew Ng氏が提唱したのか。知らなかった。。。
• 紹介してる製品多くてすごい。DevinとかAI Scientistとか有名なのは知ってるけど、他にもこんなにあったのか。これだけ玉石混合の中集めたのすごい

第2章 AIエージェントの構成

2.1AIエージェントの内部構成

2.1.1AIエージェントの構成図

• AIエージェントには「プロフィール、メモリ、計画、行動、知覚、自己修正」があるとのこと
  • 知覚ってよくわからないけど、環境からの情報得ることを知覚と呼んでいるみたい
  • 自己修正は他のエージェント（別のコンテキストを持ったLLM）にさせるべきではないのかな
  • これから言及されるのかな。たのしみ

2.1.2 AIエージェントの環境

• 「環境」に関する記述があった。この用語ちょっとよくわからなかったからありがたい
  • 環境とは、AIエージェントがタスクを実行するときに行動、知覚する場所のこと
    • コード実行環境、ブラウザ、アプリ、ゲーム、クラウド、等のコンピュータ環境
    • カメラ、センサー、スマートデバイス、ロボット、ドローン、等の物理環境
    • シミュレーション環境もある。現実世界を模倣した仮想環境
  • ツール呼び出しやMCPは環境とAIエージェントをつなぐインターフェース
  • なるほどなー。私はこれまでこれらをすべて「ツール」と呼んでいたかも。でもこの本では「ツール」はあくまでインターフェースであるとしている。たしかにそっちの方が言葉が狭くて良いな。

2.2 プロフィール（Profile）

2.2.1 プロフィールとは

2.2.2 実装上で気をつけることcolumn 知覚（Perception）

• 「知覚」について。これもよくわからなかったのでcolumnがあって助かる
  • 知覚はAIエージェントの目と耳の役割を担う機能
  • 環境からの複雑な情報を整理し、AIエージェントの計画や行動で扱いやすくする役割もある
  • 環境からの情報はテキストだけでなく、音声、画像、動画も含まれ、それらはマルチモーダルLLMを用いてマルチモーダル認識する
  • さらに、知覚機能は知覚した内容を計画や行動に反映することが求めらる
  • うーん、、、環境から得た情報全般のことを言っているのかな。IoTとかロボティクス的な文脈であれば「知覚」という言葉は理解しやすいけど、テキストや図がメインの場合は「知覚」なんて言わないよな
  • 要は知覚とは、情報を受け取り、意味を理解し、計画なり行動なりに繋げるためのものってことなんだろうな

2.3 ツール呼び出し

2.3.1 ツール呼び出しとは

2.3.2 ツールの設計において気を付けたいこと

• ツール呼び出しでは説明を詳細に記述するのが大事
  • 道具を利用するための技術的な推論は、対象行為をどのように行うかという手続き記憶と、事実や出来事を言葉で説明する知識という宣言的記憶による知的作業の、中核的な認知プロセスである。らしい
  • は？？？って感じだから整理する
  • 要は、何かしようってなったときに、なにを（what。宣言的記憶）どうやるか（how。手続き記憶）が大事ってことだと理解した
  • LLMにおけるツール呼び出しでも、この手続き記憶と宣言的記憶の両方が大事とのこと。なるほどなー

column Model Context Protocol

2.4 計画（Planning）

2.4.1 計画とは

• 事前に立てるオフライン計画と、進めながら決めるオンライン計画がある
• 2種類の計画方針
  • タスク計画
    • 大きな問題を小さな問題んに分割する方針
    • いわゆるタスク分解。よくあるやつ
  • 行動計画
    • タスクを解決するまでの実行可能な一連のステップ
    • Webページならスクロールとかクリックとか、ロボットなら移動とか
    • ステップ間の依存関係、計画変更、制約条件の考慮が大事

2.4.2 実装上で気をつけること

• 計画作成はLLMには難しい
• 推論モデル (LRM: Large Reasoning Model) は割と強い
• この本ではLLMとLRMを明確に使い分けてるっぽい。良い
• 計画生成手法がたくさん紹介されている。必要になったら読もう

2.5 自己修正（Self-Correction）

• ここでいう自己修正とは、出力の精度を自身で確認させるみたいなことではなく、外部から得た情報が微妙だったときに、ツールの叩き方間違えてないか自己言及することを言っている
  • 追記: いや、それも含めて、広い概念。自己修正というか、出力検証の話

2.5.1 自己修正とは

• 自己修正の方法
  • 内在的: LLM自身の能力に基づく修正方法
    • Reflection: 出力を自身で確認するやり方
    • Self-Consistency: 誤りを批評するのではなく、複数回生成を実施し、最も一貫性のある回答を採用するやり方。アンサンブルに近いが、平均を採用するのではなく、最も一貫性のあるひとつのみを選抜する
    • Muti-Agent Debate: 複数のエージェントに議論させるやり方
    • Thinking Process Evaluation: 結果ではなくプロセスを評価するやり方。CoTやToTのような思考過程を出力するタイプの生成に有効
  • 外在的: 外部ツールや知識のフィードバックに基づく修正方法
    • 外部ツールの実行結果のフィードバック: 例えばコード生成の場合、処理の実行結果のエラー出力をフィードバックとして与え、評価し、再生成するやり方
    • 知識のフィードバック: 回答が正しいかどうかをWikipedia等の文書と比較するやり方。人間が定めた評価基準との比較もこれ。
    • 人間からのフィードバック: 人間にチェックしてもらうやり方
  • なるほどなー。全部知ってはいたけど、こうやって整理されると明確にどれを選ぼうかっていう発想になっていいね。

2.5.2 実装上で気をつけること

• 内在的な方法は頭打ちになりやすい。劣化することさえある。できるなら外在的な方法を推奨
• 自己修正のタイミングは、適切な外部フィードバックが与えられるポイント。正確な評価指標もなく改善なんて無理。プログミングならエラー結果とか文章生成なら評価基準とかがないとどうにもならない
• 自己修正の責務を超えて修正させないのもポイント。文章作成なら、作成フェーズのまま評価フェーズに移行するとうまくいかない。作成は作成、評価は評価でやる。要はコンテキストエンジニアリング

2.6 メモリ（Memory）

2.6.1 メモリとは

2.6.2 実装上で気をつけること

• お、「コンテキスト管理」というワードが出てきた。いいね

2.7 シングルエージェントワークフロー

2.7.1 シングルエージェントワークフローとは

• シングルエージェントワークフローの設計パターン
  • Plan-and-Execute型: タスク要求が与えられると同時に実行手順を決定する
    • あらかじめ用途やツールが限定されている場合に有用
  • インターリープ型: タスク要求や直前のサブタスクの実行結果から次のサブタスクを逐次的に決定していく
    • 「思考→行動→観測」を逐次的に繰り返すことでタスク達成を目指すやり方
    • LangChainやLlamaIndex等のライブラリで定義されており実装が簡単
    • 汎用性が高い
    • Coding AIはこれが主軸かな？コーディング→エラー→このエラーは〇〇が原因ぽいので、〇〇します→その結果、、、みたいなやつ
    • というか "AIエージェント" って最低限これを指している気がする
  • シミュレーション型: 直近のサブタスク系列の候補をシミュレートしてその結果をもとに次のサブタスクを逐次的に決定していく
    • 与えられたタスク要求から、モンテカルロ期探索という強化学習でも使用される探索アルゴリズムを用いて探索的に行動選択することでタスク達成を目指す
    • 物理的な環境下での配送や組み立て、戦略的な問題解決が必要な旅行計画など、複雑で動的な場合に有用
    • 実行時間、APIコストが高くなりがち
    • なんか難しいこと言ってるけど要は、実際には行動せずに、頭の中だけで行動をシミュレーションして、ベストなものを選ぶ、ってことだよなたぶん
    • インターリープ型と似てるけど、実際に行動するかどうかが違っている
      • インターリープ型はWeb検索とか、ミスったらやり直せばいい系のやつに向いてるけど、
      • ミスったらやばい系の、例えば運転とかはシミュレーション型が向いてると理解した

2.7.2 実装上で気をつけることcolumn AIワークフロー

• 「AIワークフロー」と「エージェントワークフロー」の違い
  • AIワークフローは、要は従来のワークフロー（パイプライン）。ただ各ステップの実行がAIになっただけ
  • エージェントワークフローは、ワークフローがベースではあるものの、行動結果をもとに次の行動を決めるのが大きな違い

2.8 マルチエージェントワークフロー

2.8.1 マルチエージェントワークフローとは

• 各エージェントの責務を小さくすることで、総合的な性能向上を期待する
• マルチエージェントワークフローの設計パターン
  • フラットな関係で対話・討論
    • アイデア出し、ブレスト的な場面で有用
  • 組織的な階層構造で問題解決: マネージャ+実行者
    • 汎用的な業務に有用
    • ユースケース: 機能の多いサービスの問い合わせ対応
    • これが最も一般的かな？そういうのも書いて欲しいな。主観的でいいから。
  • 業務プロセスの再現で問題解決: 業務プロセスに登場する職業を描くエージェントが担い、業務プロセスの流れに沿って強調する
    • これもよく見るかも？
    • エージェントワークフローにはピッタリな気がするけど、どうなんだろ
  • 人間社会をシミュレーション（World Simulation）
    • 評価や交渉のシミュレーションに有用
    • おもしろいけど、案件では採用されづらいやつ
  • 各設計パターンが固有名詞になってなくてなんか変。シングルはなってたのに。名前ないのかな？ありそうだけどな
  • 研究やエンタメ枠ではなく、案件で使うなら2か3な気がする。どうだろ。どう？

2.8.2 実装上で気をつけること

• マルチエージェントワークフローが適しているケースについて

  • マルチはシングルの発展系ではない。むしろシングルの方が設計が難しいこともある
  • まず業務プロセスを整理し、
    • 意思決定が必要な箇所
    • ツールを必要とする箇所
    • 作業が分担される箇所
    • 専門的な知識が必要となる箇所
  • で区切り、それぞれで必要な能力や目的が違うのであればエージェントを分け、マルチエージェントワークフローの設計を検討する
  • ここめっちゃ重要なこと言ってる！！！
  • なるほどなー。AIエージェントとは言うけど、まずは業務整理なのか。次にエージェントベースでの設計を考えるのか
  • ここめっちゃ知りたかった！助かる！！
  • これ進めると自然と3の設計パターンになりそうだけど、それでいいのかな。作ってみようの章では設計から取り上げられて欲しい。期待

• 最も重要な役割は、実行結果の評価

  • 評価者がいるかどうかがタスクの成功率に大きく関わることが研究で知られている
  • なるほど。評価が大事なのか。評価って言っても、具体的にどこがどうダメとか、その基準が明確で正しくある必要もあるよな。
  • そもそも評価できるタスクに分けないといけないんだな。なるほどー。学びがある
    column 推論モデルはAIエージェントに役立つのか

• LRMは計画に役立つ

  • 例えばo1で計画、4oで実行という設計が良い
  • 自己修正能力は高くない

2.9 まとめ