【AIエージェント】AIエージェント技術シラバス|AIに作らてみた

AIエージェントの勉強をしたいと思っていたのですが、何から学べばよいかなと思ってました。
すると「AIエージェント・ストラテジスト認定資格」なる資格を発見し、これは良いなと思いシラバスを見て、AIにセクション分けしてもらいました。

しかし、ストラテジストの名の通り、戦略系が多く技術系の用語があまりない。。
というわけで、シラバスをサンプルで渡して、チャッピーに創作してもらった次第です。

調査するの大変なので助かるところです。
当然精度は100%ではないので、1つずつ調べるごとに改廃していこうかなと思っています。

チャプターとかは元の資格のシラバスの名残です、はい。


🧠 Chapter 1:LLMとAIエージェントの基礎(Section 1〜5)

AIエージェントの「脳」となるLLMの仕組みから、プロンプト、コンテキスト、推論まで、AIエージェントを理解するための土台を学びます。

Section 1:LLMの基本

  • LLM(大規模言語モデル):大量のデータを学習し、文章の理解や生成などを行う言語モデル。
  • トークン:LLMが文章を処理する際に扱う基本的な単位。
  • 次トークン予測:これまでの入力をもとに、次に現れる可能性が高いトークンを予測するLLMの基本的な仕組み。
  • コンテキスト:LLMが現在の処理に利用する入力情報や、その背景となる情報。
  • コンテキストウィンドウ:LLMが1回の処理で扱えるトークン量の範囲。

Section 2:TransformerとLLMの構造

  • Transformer:現在の多くのLLMの基盤となっているニューラルネットワークのアーキテクチャ。
  • Attention(注意機構):入力された情報同士の関係性を計算し、どの情報に注目するかを決める仕組み。
  • Self-Attention(自己注意機構):入力されたトークン同士の関係性を計算するAttentionの仕組み。
  • 埋め込み(Embedding):単語や文章などの情報を数値ベクトルとして表現する技術。
  • 推論:学習済みモデルを使って、入力に対する出力を生成する処理。

Section 3:プロンプトとコンテキスト

  • プロンプト:LLMに与える指示や入力情報。
  • システムプロンプト:AIの役割、ルール、基本的な振る舞いなどを定義する指示。
  • ユーザープロンプト:ユーザーから与えられる具体的な指示。
  • Few-shot(フューショット):複数の具体例を提示し、LLMに期待する回答パターンを示す方法。
  • 構造化出力(Structured Output):JSONなど、あらかじめ決められた形式でLLMに出力させる方法。
  • コンテキスト設計:LLMにどの情報を、どのような形式や順序で与えるかを設計すること。

Section 4:LLMの推論

  • 推論能力:与えられた情報を組み合わせ、問題の解決や判断を行う能力。
  • Chain-of-Thought(CoT / 思考の連鎖):複雑な問題を解く際の推論過程を利用する代表的な手法。
  • 推論モデル:複雑な問題に対して、推論により多くの計算資源を使うよう設計されたモデル。
  • Temperature(温度):LLMが生成する結果の確率分布のばらつきを調整するパラメータ。
  • ハルシネーション:LLMが事実とは異なる内容を、もっともらしく生成する現象。

Section 5:LLMとプログラムの違い

  • LLM:自然言語などを入力として、学習したパターンをもとに出力を生成するモデル。
  • プログラム:あらかじめ定義された処理を、決められたルールに従って実行する仕組み。
  • 決定的処理:同じ条件で基本的に同じ結果を返す処理。
  • 非決定的処理:同じ入力でも、設定や確率的な性質によって異なる出力が生じ得る処理。
  • LLM+プログラム:LLMの柔軟な判断と、プログラムの正確な処理能力を組み合わせる考え方。

🤖 Chapter 2:エージェントの思考と行動(Section 6〜10)

LLMを単なるチャットボットから、目的に向かって判断・行動するAIエージェントへ発展させるための基本構造を学びます。

Section 6:AIエージェントの基本ループ

  • 目標(Goal):エージェントが達成すべき目的。
  • 推論(Reasoning):現在の状況から、次に何をすべきか判断する処理。
  • 行動(Action):判断した内容を実際に実行する処理。
  • 観察(Observation):行動した結果を取得し、次の判断に利用すること。
  • エージェントループ:推論、行動、結果の確認などを繰り返しながら目標達成を目指す基本構造。

Section 7:ReActとエージェントパターン

  • ReAct(Reasoning + Acting):推論と行動を組み合わせ、外部環境から得た結果を次の判断に利用する代表的な設計パターン。
  • Thought(思考):次の行動を決定するための推論。
  • Action(行動):外部ツールなどに対して実行する処理。
  • Observation(観察):行動によって得られた結果。
  • エージェントパターン:AIエージェントを設計する際に利用できる代表的な構造や設計方法。

Section 8:プランニングとタスク分解

  • プランニング(Planning):目標を達成するための手順や計画を立てること。
  • タスク分解:大きなタスクを複数の小さなタスクへ分解すること。
  • サブタスク:大きなタスクを構成する個別の作業。
  • タスクツリー:タスクを階層構造で分解して表現する方法。
  • 動的プランニング(Dynamic Planning):実行途中で得られた情報に応じて計画を変更する仕組み。

Section 9:リフレクションと自己修正

  • リフレクション(Reflection):自分の出力や行動結果を評価し、改善につなげる仕組み。
  • 自己修正(Self-Correction):エラーや不適切な結果を検出し、処理を修正すること。
  • 批評役(Critic):生成された結果を評価する役割。
  • 検証役(Verifier):回答や処理結果が条件を満たしているか検証する仕組み。
  • 再試行(Retry):失敗した処理を条件や方法を変えて再実行すること。

Section 10:エージェントの自律性

  • 自律性(Autonomy):人間から逐一指示を受けずに、エージェント自身が判断・行動する度合い。
  • 人間参加型(Human-in-the-Loop):重要な判断や処理に人間を介在させる設計。
  • 人間による監督(Human-on-the-Loop):基本的にはAIが処理し、必要な場合に人間が監督する考え方。
  • 人間非介在型(Human-out-of-the-Loop):人間の介入なしに処理を完結させる設計。
  • 承認ポイント:AIの処理を一時停止し、人間による確認や承認を求める地点。

🔧 Chapter 3:ツールとファンクションコーリング(Section 11〜15)

LLMに「手足」を与え、外部の情報やプログラムを利用させる仕組みを学びます。

Section 11:ファンクションコーリングの基本

  • ファンクションコーリング(Function Calling):LLMが外部の関数を呼び出すための情報を生成する仕組み。
  • ツールコーリング(Tool Calling):LLMから外部ツールを利用するための仕組み。
  • 関数:特定の処理を実行するプログラム上の処理単位。
  • ツール:AIエージェントが利用できる外部機能。
  • 引数(Arguments):関数やツールに渡す具体的な値。

Section 12:ツール実行の仕組み

  • ツール選択(Tool Selection):複数のツールから、目的に適したものを選択すること。
  • ツールスキーマ(Tool Schema):ツールの名前、説明、引数などを定義した仕様。
  • ツール呼び出し(Tool Call):LLMがツールを呼び出すために生成する要求。
  • ツール結果(Tool Result):ツールを実行した結果として返される情報。
  • ツール実行:LLMからの要求を受け、実際にプログラムやAPIを実行する処理。

Section 13:APIと外部システム連携

  • API:異なるソフトウェア同士が機能やデータを利用するためのインターフェース。
  • REST API:HTTPを利用してシステム間でデータをやり取りする代表的なAPI方式。
  • 認証(Authentication):APIを利用するユーザーやシステムを確認する仕組み。
  • 認可(Authorization):認証されたユーザーやシステムに、どの操作を許可するかを決める仕組み。
  • Webhook:あるシステムでイベントが発生した際に、別のシステムへ通知する仕組み。

Section 14:ツール利用型エージェント

  • ツール利用型エージェント:外部ツールを利用しながらタスクを実行するエージェント。
  • 検索ツール:Webやデータベースなどから情報を取得するツール。
  • 計算ツール:LLMの代わりに正確な計算を実行するツール。
  • コード実行:エージェントがプログラムを実行して処理する仕組み。
  • ブラウザ操作:Webページを読み取り、クリックや入力などの操作を行う仕組み。

Section 15:ツール利用の安全設計

  • 最小権限:エージェントに必要最低限の権限だけを与える考え方。
  • 許可リスト:利用可能なツールや操作をあらかじめ限定する仕組み。
  • 確認・承認:メール送信やデータ削除など、高リスクな操作の前に人間の承認を求める仕組み。
  • サンドボックス:外部への影響を制限した隔離された実行環境。
  • ツール用ガードレール:危険なツール利用を検知・制限する仕組み。

💾 Chapter 4:メモリとコンテキスト管理(Section 16〜20)

エージェントが「今の会話」だけではなく、過去の情報を利用して処理するためのメモリとコンテキスト管理を学びます。

Section 16:AIエージェントのメモリ

  • メモリ(Memory):エージェントが過去の情報を保存し、後から利用するための仕組み。
  • ワーキングメモリ(Working Memory):現在のタスクを処理するために一時的に保持する情報。
  • 短期記憶(Short-term Memory):現在の会話やタスクなど、比較的短期間利用する情報。
  • 長期記憶(Long-term Memory):外部の保存領域などに保存し、後から再利用する情報。
  • エピソード記憶(Episodic Memory):過去に起きた出来事や処理履歴を記録する記憶。

Section 17:メモリの保存と検索

  • メモリストア(Memory Store):エージェントの記憶を保存する仕組み。
  • メモリ検索(Memory Retrieval):必要な記憶を検索して取り出す処理。
  • 埋め込み(Embedding):情報をベクトルとして表現する技術。
  • ベクトルデータベース:ベクトル化した情報を保存・検索するデータベース。
  • 意味検索(Semantic Retrieval):情報の意味的な関連性を利用して記憶を検索する方法。

Section 18:コンテキスト管理

  • コンテキスト管理:LLMに渡す情報量や内容を管理すること。
  • コンテキストウィンドウ:LLMが一度に処理できる情報量の範囲。
  • コンテキスト圧縮:大量の情報を要約・圧縮してコンテキストに収める技術。
  • 要約(Summarization):過去の会話や処理結果を短くまとめること。
  • コンテキスト選択:大量の情報から、現在のタスクに必要な情報だけを選択すること。

Section 19:メモリの設計

  • 記憶の書き込み:どの情報をメモリとして保存するかを決定する処理。
  • 記憶の読み出し:現在のタスクに必要な過去情報を取得する処理。
  • 記憶の更新:古くなった情報や誤った情報を修正する処理。
  • 記憶の削除:不要になった情報を削除する処理。
  • 記憶の関連付け:人物、出来事、知識などの情報同士の関係を保持する考え方。

Section 20:メモリとRAGの違い

  • メモリ:エージェントの過去の会話、利用者の情報、過去の出来事などを再利用する仕組み。
  • ナレッジベース:企業文書やマニュアルなど、外部の知識を保存する場所。
  • RAG:外部の知識を検索してLLMの生成に利用する仕組み。
  • 個人化(Personalization):ユーザーの好みや過去の利用履歴などを利用して応答を個人化すること。
  • メモリとRAGの使い分け:何を「記憶」として保持し、何を「知識」として検索するのかを設計すること。

📚 Chapter 5:RAGと知識検索(Section 21〜25)

エージェントが外部の知識を検索し、必要な情報を取得して利用する仕組みを学びます。

Section 21:RAGの基本構造

  • RAG(検索拡張生成):外部情報を検索し、その結果をLLMの生成に利用する仕組み。
  • 検索・取得(Retrieval):必要な情報を検索・取得する処理。
  • 情報付加(Augmentation):検索結果をLLMへの入力情報として追加する処理。
  • 生成(Generation):取得した情報をもとにLLMが回答を生成する処理。
  • ナレッジベース:RAGが参照する文書やデータの集合。

Section 22:データ取り込み

  • 文書読み込み(Document Loader):PDF、Webページなどの外部データをシステムに取り込む処理。
  • 解析(Parsing):文書やファイルから必要な情報を読み取る処理。
  • チャンク分割(Chunking):長い文書を検索しやすい単位に分割する処理。
  • メタデータ:文書の作成者、日時、カテゴリなどの付随情報。
  • インデックス作成(Indexing):検索しやすいようにデータを整理・登録する処理。

Section 23:検索方式

  • キーワード検索:入力されたキーワードをもとに情報を検索する方法。
  • ベクトル検索:文章をベクトル化し、意味的な近さを利用して検索する方法。
  • セマンティック検索:検索語と情報の意味的な関連性を利用する検索。
  • ハイブリッド検索:キーワード検索とベクトル検索など、複数の検索方法を組み合わせる方式。
  • リランキング:検索結果を再評価し、より関連性の高い情報を上位に並べ替える処理。

Section 24:RAGの品質

  • 検索品質:必要な情報を正しく検索できているかを評価すること。
  • 適合率(Precision):検索結果の中に、必要な情報がどれだけ含まれているかを見る指標。
  • 再現率(Recall):必要な情報をどれだけ取りこぼさず取得できているかを見る指標。
  • 根拠に基づく生成(Grounded Generation):取得した情報を根拠として回答を生成すること。
  • 出典(Citation):回答の根拠となった情報源を示すこと。

Section 25:RAGの限界

  • 検索漏れ:必要な情報を検索できない問題。
  • 検索ノイズ:関係のない情報を検索結果として取得してしまう問題。
  • 古い情報:更新されていないデータを参照してしまう問題。
  • コンテキスト超過:検索結果を詰め込みすぎてコンテキストを圧迫する問題。
  • ハルシネーション:検索結果を利用していても、LLMが誤った内容を生成する問題。

🔄 Chapter 6:ワークフローとオーケストレーション(Section 26〜30)

複数のLLM処理やツールを組み合わせ、AIエージェント全体の処理フローを設計する知識です。

Section 26:ワークフロー

  • ワークフロー:複数の処理を決められた順番で組み合わせた処理フロー。
  • ノード:ワークフローを構成する個々の処理単位。
  • トリガー:ワークフローを開始するきっかけ。
  • アクション:実際に実行する処理。
  • 出力:処理によって生成される結果。

Section 27:条件分岐とループ

  • 条件分岐:条件によって処理するルートを変更する仕組み。
  • ループ:同じ処理を条件が満たされるまで繰り返す仕組み。
  • 反復処理(Iteration):複数のデータに対して同じ処理を繰り返すこと。
  • 例外処理:エラーや想定外の状態が発生した場合の処理。
  • 終了条件:エージェントやワークフローの処理を終了させる条件。

Section 28:オーケストレーション

  • オーケストレーション:複数のエージェント、ツール、処理を組み合わせ、全体を制御する仕組み。
  • ルーター(Router):タスクの内容に応じて適切な処理先を選択する仕組み。
  • ディスパッチャー(Dispatcher):処理を適切なエージェントやツールへ振り分ける仕組み。
  • 状態(State):現在のタスクの進行状況や保持している情報。
  • 状態管理:エージェントの状態を管理する仕組み。

Section 29:エージェント型ワークフロー

  • ワークフロー型:処理の流れをあらかじめ設計する方式。
  • エージェント型:LLMが状況に応じて次の行動を判断する方式。
  • ハイブリッド型:決められたワークフローとLLMによる自律判断を組み合わせる方式。
  • 決定的ステップ:あらかじめ処理内容が決まっているステップ。
  • エージェント型ステップ:LLMが状況に応じて判断するステップ。

Section 30:実行制御

  • タイムアウト:処理が一定時間を超えた場合に停止する仕組み。
  • 再試行:失敗した処理を再実行する仕組み。
  • フォールバック:処理に失敗した場合に別の方法へ切り替える仕組み。
  • レート制限:APIなどの利用回数を制限する仕組み。
  • コスト管理:LLMの利用料金や計算資源を管理すること。

👥 Chapter 7:マルチエージェント(Section 31〜34)

複数のエージェントを組み合わせ、複雑なタスクを分担して処理する設計を学びます。

Section 31:マルチエージェントの基本

  • マルチエージェントシステム:複数のAIエージェントが協調してタスクを処理するシステム。
  • エージェントの役割:各エージェントに与えられた担当や責任。
  • 専門化:エージェントごとに異なる専門分野を担当させる設計。
  • 委任(Delegation):上位のエージェントなどが別のエージェントへ処理を任せること。

Section 32:エージェント間の協調

  • スーパーバイザーパターン:管理役のエージェントが複数の専門エージェントを統括する構造。
  • ピア・ツー・ピア:エージェント同士が対等な立場で協調する構造。
  • 順次処理:エージェントが順番に処理を担当する方式。
  • 並列処理:複数のエージェントが同時並行で処理する方式。
  • ハンドオフ:あるエージェントから別のエージェントへ処理を引き渡す仕組み。

Section 33:マルチエージェントの設計

  • 役割設計:各エージェントの役割や責任範囲を設計すること。
  • エージェント間通信:エージェント同士で情報を受け渡す仕組み。
  • 共有状態:複数のエージェントが共有する状態や情報。
  • 競合解決:エージェント間で意見や判断が一致しない場合の処理。
  • 協調:複数のエージェントの行動を調整すること。

Section 34:マルチエージェントの限界

  • 通信コスト:エージェント間のやり取りが増えることで発生する計算・時間・料金のコスト。
  • 複雑性:エージェントが増えることでシステム全体の挙動が把握しにくくなる問題。
  • エラー伝播:一つのエージェントの誤りが後続の処理へ伝わる問題。
  • 協調失敗:複数のエージェントが適切に協調できない問題。
  • 過剰設計:単一エージェントで十分な処理を、必要以上に複数エージェント化してしまうこと。

🛡️ Chapter 8:評価・安全性・運用(Section 35〜40)

AIエージェントを「動かす」だけではなく、正しく動いているか、安全に使えるかを評価・管理するための知識です。

Section 35:エージェントの評価

  • 評価(Evaluation):エージェントの性能や品質を測定すること。
  • タスク成功率:指定されたタスクを最後まで達成できた割合。
  • 正確性(Accuracy):回答や判断が正しかった割合。
  • レイテンシ:処理開始から結果が返るまでの時間。
  • タスクあたりコスト:1タスクを処理するために必要なコスト。

Section 36:LLMの評価

  • LLMによる評価(LLM-as-a-Judge):別のLLMを評価者として利用する方法。
  • 正解データとの比較評価:正解データと生成結果を比較する評価方法。
  • 正解データを使わない評価:明確な正解を用意せず、品質基準などから評価する方法。
  • 人間による評価:人間が実際の出力を確認して評価する方法。
  • ベンチマーク:性能を比較するための標準的な評価基準やデータセット。

Section 37:可観測性

  • 可観測性(Observability):エージェントが内部で何をしているのかを把握できる状態。
  • トレース:1回の処理における一連の実行履歴。
  • ログ:処理中に発生したイベントを記録した情報。
  • トークン使用量:LLMが処理に使用したトークン量。
  • 監視(Monitoring):稼働中のシステムを継続的に監視すること。

Section 38:エージェントのセキュリティ

  • プロンプトインジェクション:悪意のある指示によってLLMやエージェントの挙動を操作する攻撃。
  • 間接的プロンプトインジェクション:Webページや文書など、外部から取得したデータに悪意のある指示を埋め込む攻撃。
  • 情報漏えい:機密情報などが意図せず外部へ流出する問題。
  • 権限昇格:本来許可されていない権限を取得・利用する問題。
  • サンドボックス化:危険な処理を隔離された環境で実行する仕組み。

Section 39:ガードレール

  • ガードレール:AIの入力・出力・行動を制限し、安全性を確保する仕組み。
  • 入力ガードレール:危険な入力や不適切な要求を検知する仕組み。
  • 出力ガードレール:生成された回答がルールに違反していないか確認する仕組み。
  • 行動ガードレール:外部ツールの実行内容を制限する仕組み。
  • ポリシー:エージェントが守るべきルールや制約。

Section 40:エージェント運用

  • エージェント運用(AgentOps):AIエージェントを継続的に運用・監視・改善するための考え方。
  • バージョン管理:プロンプト、モデル、ツール、ワークフローなどのバージョンを管理すること。
  • 回帰テスト:変更によって以前できていた処理ができなくなっていないか確認するテスト。
  • ロールバック:問題が発生した場合に以前のバージョンへ戻すこと。
  • 継続的改善:運用データをもとに継続的にエージェントを改善すること。

🔌 Chapter 9:AIエージェントの接続と標準化(Section 41〜44)

AIエージェントが外部のツールやデータと接続する際に必要となる、APIやMCPなどの標準化技術を学びます。

Section 41:APIによるシステム連携

  • API:異なるソフトウェア同士が機能やデータを利用するためのインターフェース。
  • REST API:HTTPを利用してシステム間でデータをやり取りする代表的なAPI方式。
  • 認証:APIを利用するユーザーやシステムを確認する仕組み。
  • 認可:認証されたユーザーやシステムに、どの操作を許可するかを決める仕組み。
  • APIキー / OAuth:APIなどの利用者を識別・認証するために利用される代表的な仕組み。

Section 42:MCPの基本

  • MCP(Model Context Protocol):AIアプリケーションと外部のツールやデータなどを接続するための標準化されたプロトコル。
  • MCPホスト:MCPを利用するAIアプリケーション側のホスト。
  • MCPクライアント:MCPサーバーと通信するクライアント。
  • MCPサーバー:AIアプリケーションにツールやデータなどの機能を提供するサーバー。
  • ツール・リソース・プロンプト:MCPで提供・利用される主要な機能や情報の概念。

Section 43:エージェント間・システム間連携

  • プロトコル:システム同士が通信するためのルール。
  • 相互運用性(Interoperability):異なるシステムやエージェントが連携して動作できる性質。
  • エージェント間連携(Agent-to-Agent):異なるエージェント同士が協調してタスクを処理する考え方。
  • サービスディスカバリ:利用可能なサービスやエージェントを発見する仕組み。
  • 委任:あるエージェントが別のエージェントへ処理を任せる仕組み。

Section 44:標準化の意味

  • 標準プロトコル:異なるシステム間で共通して利用できる通信・連携ルール。
  • 相互運用性:異なるAI製品やシステムを組み合わせられる性質。
  • 移植性(Portability):特定の環境に依存せず、別の環境へ移行しやすい性質。
  • ベンダーロックイン:特定の企業やサービスに依存し、他の環境へ移行しにくくなる状態。
  • オープン標準:特定の企業だけに閉じず、広く利用・実装できる標準仕様。

タイトルとURLをコピーしました