Skip to content

DNET_UdemyAgenticAI

Jump to bottom
nishi_74322014 edited this page Sep 11, 2026 · 1 revision

The Complete Agentic AI Engineering Course (2025)

概要

このコースは、経験豊富なプログラマーの方から、初心者の方まで、
Agentic AIの変革の可能性を探求したい方に最適です。
自律型AIエージェントの設計、構築、導入スキルを習得し、
現実世界のビジネス課題の解決を支援します。
実践的なプロジェクトに積極的に参加することで、刺激を受け、
需要の高い専門知識を習得できます。
この刺激的な旅にご参加いただき、AIの世界であなたの未来を切り開きましょう！

  • 第1週：基礎を学ぶ

    • PJ1：キャリアアバター（自己紹介AIエージェント）：
      将来の雇用主にあなたを代表する独自のエージェントを構築して展開。

  • 第2週：OpenAI Agents SDKを学ぶ

    • PJ2：即席のSDR（セールス・ディベロップメント・レプレゼンタティブ）エージェント：
      プロフェッショナルなメールを作成して送信する営業担当者を作成。
    • PJ3：独自のDeep Researchエージェント：OpenAIのホスト型ツールを使用して
      任意のトピックについて徹底的な調査を行うエージェント・チームを実装。

  • 第3週：CrewAI を学ぶ

    • PJ4：財務調査・分析エージェント（Stock Picker）：
      CrewAI を使用して数分で構築し、良い投資先の検索を自動化。
    • PJ5：4エージェント・エンジニアリング・チーム：
      Docker上にCrewAIの独自エージェント・チームを展開してアプリを開発。

  • 第4週：LangGraphを学ぶ

    • PJ6：OpenAIのAIエージェント「Operator」の独自バージョン、
      相棒・相方（Sidekick）：コレは、LangGraphを介してブラウザー内で連携。

  • 第5週：AutoGenを学ぶ

    • PJ7：AutoGenを使用して新しいエージェントを構築および起動し、
      無限の AI の可能性を解き放つAgent Creator：

  • 第6週：MCP を学ぶ

    • PJ8：最終課題（集大成）：6 台の MCP サーバーと 44 個のツールを活用し、
      4 人のエージェントが自律的に取引を行うトレーディング フロアを構築。

詳細

  • 前提

  • 解説

    • 英語版のトランスクリプトは微妙なので日本語版を選択する。
      しかし、時間の関係からか、講師はコードの詳細をあまり解説できていない。
    • 幸いにも、詳細の解説はGitHub上にコードが配置されているので、
      Copilotに生成して貰う事で代替できる。講師より詳細に説明してくれる。
    • 余談：日本語版と英語版を比べると、
      日本語版が最新版（英語版とGitHub実装）に追いついていないケースが
      エージェント版で観測されたので、そういうケースもありそうだと認識しておくと良いかも。

  • その他、個人的に思ったコト...

    • まず、LLMエージェントについてコチラを見ておく。

    • 何故、自前で実装する？
      → SDKでカスタム開発されたエージェントが、
      特化型のタスクにおいて顕著な性能差を示すため。

      • ローコードの汎用エージェント ＜ ライブラリの汎用エージェント
        ＜ SDKで開発されたカスタム・エージェント
      • ローコードは設定可能な範囲が限られ、微調整や複雑な条件分岐が困難、
        SDKカスタムは、内部のデータ、アルゴリズムまで制御可能
      • 出力制御と品質保証：関数呼び出しだけでは
        「応答が壊れていた場合のハンドリング」が弱いので、
        結果のバリデーション + 評価ループによる再実行を書く必要あり。
      • 複数エージェントやツールのオーケストレーション：
        複数のツール選択やハンドオフ制御は、単純な関数呼び出しではなく
        「フロー制御」が必要

    • 何故、複数のフレームワークを紹介する？
      → エージェントはタスクが複雑で多様で、抽象化レイヤーが多く、
      フレームワークごとに得意領域が異なる。

      • このため、エージェント設計では「どのフレームワークを使うか」が
        パフォーマンスや拡張性に直結する。
      • 様々なフレームワークに触れておくことで、
        最適な選択を可能にする選択・比較能力の養成が目的。

前提ソフト

環境

※ Cursor IDEは、VS Code＋GitHubに切り替えても良い。
なお、可視性は、JupyterLabの方が良い。

パッケージ

  • LLMクライアント

    • OpenAI
    • Anthropic：OpenAI SDK互換性を2025/8/1に停止
      （ClaudeでGPT-5の開発を支援していたとか）
    • LightLLM：LangChainのような複雑な構造がなく、あらゆるLLMに簡単に接続。

  • UI（Gradio、Streamlit）

  • LLM向けフレームワーク

  • エージェント

  • データストア

    • SQLite
    • Chroma

  • Agentツール

    • langchain_community
      • FileManagementToolkit：ローカルファイルと対話
      • GoogleSerperAPIWrapper：Google検索Serper APIのラッパ
      • WikipediaAPIWrapper：Wikipedia検索MediaWiki APIのラッパ
      • PlayWrightBrowserToolkit：次世代Selenium、MS製 - UIオートメーション
      • PythonREPLTool：対話型実行環境(≒即時実行結果確認)ツール

アプリ

  • JupyterLab

  • Cursor IDE
    VS CodeベースのAI支援機能を搭載したコードエディタで
    Jupyterの代替にNotebook系の開発に使える。

  • Visual Studio Code
    ...と言う事は、VS Code＋GitHubでも、大凡、Cursor IDEと同じ様に使える。

サービス

  • OpenAI、Anthropic、Gemini、DeepSeek、Groq

  • OpenRouter（紹介のみ、互換API、課金の一本化）

  • MCPサーバー

    • Brave Search
    • Polygon.io Alpha Vantage API

  • Serper API

  • MediaWiki API

  • Pushover（✕ Twilio）

  • SendGrid（→ Resend）

Week1

Day1（Week1）

  • 内容

    • 自律型AIエージェントデモ：n8nを使ったスマートホームデバイスの制御
    • AIエージェントフレームワーク解説：OpenAI SDK、CrewAI、LangGraph、AutoGen
    • エージェント開発環境のセットアップ：Cursor IDE、UV、APIオプションの理解
    • WindowsでのAI開発環境セットアップ：Git、Cursor IDE、UVパッケージマネージャー
    • MacでのAIプロジェクトセットアップ：GitHub、Cursor IDE、OpenAI APIキー
    • 初めてのエージェントAIワークフロー構築：OpenAI APIを使ったステップバイステップガイド
    • エージェントAI入門：自律性を持つマルチステップLLMワークフローの作成

  • 要約

    • n8n というローコード／ノーコードのワークフローアプリを用いて、
      生成AIとツールを組み合わせたエージェントの動作例を実演。
    • LLMチャットから、Philips Hueの照明制御ツールを接続し部屋の電球を点灯・色変更
      （Philips Hue MCPサーバー）。
    • 今後のコースではローコードツールを離れ、実際にコードを書いてAIエージェントを構築し、
      複数のエージェントを連携させて問題解決に挑む
    • コーディング開始前に環境設定が必要。IDEは Cursor IDE、
      仮想環境管理には UV を使用（Anacondaの代替）。
    • 環境設定：Windows/Mac/Linux（GitHubリポジトリの取得 → Cursor IDE導入 →
      uvで環境構築 → OpenAI APIキー設定 → .envファイル作成）
    • 演習課題：エージェント的 (1) LLMにビジネスセクターを選ばせる
      (2) そのセクターのペインポイントを特定させる (3) AIソリューションを提案させる

  • コンテンツ

Day2（Week1）

（座学）

  • 内容

    • 効果的なエージェントの構築：LLMの自律性とツール連携の解説
    • 堅牢なAIシステムを構築するための5つの必須LLMワークフローデザインパターン
    • LLMアプリケーション設計におけるエージェントパターンとワークフローパターンの理解

  • 要約
    エージェントの定義は曖昧だが「エージェントアーキテクチャ」の理論解説。

    • 一般的な特徴：複数LLM呼び出し、ツール使用、連携、プランナー、自律性。
    • Hugging Faceの定義：LLMの出力がワークフローを制御するプログラム
    • Anthropicの区分：ワークフロー vs エージェント
    • 多くの「エージェント」と呼ばれるものは実際にはワークフロー
    • エージェントの定義（エージェントらしさ、デザインパターン）
      （LLMエージェントの該当節を参照）

Day3（Week1）

  • 内容

    • 複数LLMのオーケストレーション：GPT-4o、Claude、Gemini、DeepSeekの比較
    • マルチLLM API連携：OpenAI、Anthropic、その他のモデルの比較
    • LLM APIの比較：OpenAIクライアント・ライブラリでClaude、Geminiなどを利用する
    • 複数LLMのオーケストレーション：AIの応答を評価するシステムの構築
    • エージェントのデザインパターンとツール利用の連携：AI構築に不可欠な要素

  • 要約
    「エージェント型ワークフローの構築」と「複数LLMのオーケストレーション」に焦点

    • 使用モデル（OpenAI、Claude、Gemini、DeepSeek、Groq、Ollama）を
      Vellum Leaderboardで比較
    • Cursor IDE上で複数のLLMを設定・呼び出し、
      応答を取得・比較しながら学ぶ実践型ラボ
    • Anthropic以外、OpenAI互換API形式を採用。
      ローカル実行はリソースに依存、適切なモデルを選択。
    • 複数LLMの回答を評価・順位付けするPythonモデル間オーケストレーション実装と商業的応用例

  • コンテンツ

Day4（Week1）

  • 内容

    • AIエージェントフレームワークの比較：LLMオーケストレーションにおけるシンプルさとパワー
    • リソース＆ツール：エージェントAIでLLMの能力を強化する2つの方法
    • GradioとOpenAIであなたのように振る舞うキャリアアバター（経歴紹介AI）を構築
    • Geminiを使ってGPT-4の応答を評価する：マルチLLMパイプライン
    • エージェントLLMワークフローの構築：リソース、ツール、構造化出力

  • 要約

    • フレームワーク「使わない：MCP直」、「軽量：OpenAI、CrewAI」、
      「重量：LangGraph、AutoGen」
    • リソース・構造化出力・ツールを組み合わせ、エージェント的フローを構築する。
    • 「リソース：LLMの回答を強化する情報やデータ」
      「ツール：LLMに拡張アクションを実行させる手段」
      • リソース実装：GradioのUIからPyPDF2で読んでLLMに投げる
        キャリアアバター（経歴紹介AI）
      • 構造化出力：自己紹介の内容の評価を構造化出力
      • ツール実装：評価 → 再回答（今回は手書き、デバッグ技術で内部動作を把握）

  • コンテンツ

Day5（Week1）

Week2

Day1（Week2）

  • 内容

    • 非同期Pythonの理解：OpenAI Agents SDKの基礎
    • OpenAI Agents SDKの基礎：エージェントの作成、トレース、実行
    • OpenAI Agents SDK入門：Agent、Runner、Traceクラスの概要
    • Vibe Coding：LLMで効率的にコードを生成するための5つの必須テクニック
    • OpenAI Agents SDK：AI開発のためのコアコンセプトの理解

  • 要約

    • OpenAI Agents SDK

      • asyncioの基本概念を理解することが必須で、
        特にI/O待ちの多いエージェント処理で威力を発揮
      • 重要な用語：エージェント、ハンドオフ、ガードレール
      • 実行ステップ：create、with trace、await runner.run

    • バイブコーディング

      • LLMにコードを生成させ、それに少し修正を加えながら進めるアドホックな作業モード
      • 5つのヒント：① １つ１つ丁寧に、② 鵜呑みにせず、③ 検証的に、④ 段階的に、
        ⑤ 根拠含め多様な解を得る。

  • コンテンツ

Day2（Week2）

  • 内容

    • SendGrid（→ Resend）でAIセールスエージェントを構築：Agent SDKでのツールと連携
    • 並行LLM呼び出し：並列エージェント実行のためのAsyncioの実装
    • エージェントをツールに変換する：階層的なAIシステムの構築
    • エージェントの制御フロー：ハンドオフとエージェント as ツールの使い分け
    • 関数呼び出しからエージェントの自律性へ：OpenAI SDKによるセールスオートメーション
    • ビジネス向けエージェントAI：インタラクティブなセールスアウトリーチツールの作成

  • 要約

    • SendGrid（→ Resend）を使ったメール送信環境を準備し、
    • 3種類のSales Development Agentを作成してストリーミングでメールコンテンツを生成
    • OpenAIの@function_toolデコレータを使うことで、
      以前は大量のJSONを手動で書く必要があったツール化が大幅に簡略化
    • 複数のエージェントをツール化し、管理エージェントは与えられたツールを使って
      メールを生成し最良のモノを選びハンドオフで送信。
    • 「ツール化：エージェントを外部から呼び出せる道具として提供」
      「ハンドオフ化：タスクを他のエージェントやシステムに引き渡す」

  • コンテンツ

※ ハンドオフはエージェントフローを「指揮」せず「委任」の形で実装できる感じ。

Day3（Week2）

  • 内容

    • マルチモデル連携：OpenAIエージェントでGemini、DeepSeek、Groqを使用する
    • 堅牢なAIエージェントシステムのためのガードレールと構造化出力の実装
    • 実践におけるAIセーフティ：LLMエージェントアプリケーションのためのガードレールの実装

  • 要約

    • 異なるLLM（OpenAI以外含む）をAgents SDKで扱う。
      ツール化とハンドオフ、構造化出力とガードレール導入。
    • 事例から、自律型エージェントは本質的に不安定さを持ち、
      明示的制御が必要であることが確認された。
    • AnthropicのClaudeがOpenAI互換でないため
      OpenRouterやMCPプロトコルといった代替手段を紹介。
    • 「careful sales manager」というエージェントで構造化出力 →
      ガードレールでPII（個人情報）入力を防ぐ。

  • コンテンツ

Day4（Week2）

  • 内容

    • 深層リサーチエージェントの構築：OpenAIのWeb検索ツールの実装
    • プランナーエージェントの構築：AIにおけるPydanticによる構造化出力の活用
    • GPT-4エージェントと非同期タスクによるエンドツーエンドのリサーチパイプライン構築
    • 深層リサーチエージェントの構築：AsyncIOによる並列検索

  • 要約

    • Deep Researchはエージェント型AIの典型的なユースケースを紹介

      • 独自のDeep ResearchエージェントをOpenAIのホスト型ツールを使用して実装。
      • ホスト型ツールには「Web検索ツール」「ファイル検索ツール」「コンピュータ・ツール」がある。
      • 今回は「Web検索ツール」を使い、コレは、1回あたり2.5セント程度のコストがかかる。
      • 実際に「2025年の最新AIエージェントフレームワーク」を検索、
        LangChain, LangGraph, CrewAI,
        Semantic Kernel, AutoGen などの結果を得る。

    • クエリを受け取り、その調査に役立つ複数の検索クエリを考案するエージェントを作成

      • 実際に検索を行うのではなく、
        検索計画（検索すべきキーワードと理由）を構造化出力で返す。
      • 1回の検索に約2.5セントかかるため、初期設定は3回の検索に制限。
        回数を増やせば網羅性は増すがコストも上がる。
      • 構造化は、WebSearchPlan（searches = WebSearchItem（reason、query）のリスト）の
        Pydanticモデルとして出力される。
      • docstringで注釈を加えることでモデルの出力品質を高める
        （内容、意味や制約、期待する値の形式を自然言語で補足）

    • AIエージェント（検索計画、検索実行、レポート作成、メール送信）を組み合わせて
      調査レポートを作成・メール送信

    • 各エージェントを関数でラップする。関数を順次呼び出すフローを書くことで、
      エージェント・フローを実装できる。

  • コンテンツ

Day5（Week2）

Week3

Day1（Week3）

  • 内容

    • CrewAIフレームワーク：協調型AIエージェントチームの作成
    • CrewAIフレームワーク解説：エージェント、タスク、処理モードのチュートリアル
    • CrewAIとLightLLM：複数LLMを連携させる柔軟なフレームワーク
    • CrewAIチュートリアル：GPT-4o miniを使ったディベートプロジェクトのセットアップ
    • CrewAIと複数LLMでAIディベートシステムを作成する方法
    • CrewAIでAIディベートシステムを構築：異なるLLMの比較

  • 要約

    • CrewAIは uv ツールを利用しており、プロジェクトも uv ベースでセットアップされる。
    • CrewAIが提供する3つのプロダクト、Enterprise / UI Studio / Frameworkで、
      ココでは、OSSのFrameworkにフォーカス。
    • Frameworkのエージェントには、Crews：自律協調的に問題解決を行う方式と、
      Flows：決定論的で監査可能なワークフロー方式がありココでは前者にフォーカス。
    • Crewの概念：「エージェント」と「タスク」の集合体で、
      実行モードにはシーケンシャル・ヒエラルキー型がある。
      「エージェント」は「役割・目標・バックストーリー」を持ち「タスク」を処理する。
    • Crewごとに 完全なプロジェクトとディレクトリ構造 が自動生成され、
      エージェントやタスクは、@CrewBase, @agent, @crew, @taskなどのデコレータで整理、
      YAMLファイルで設定可能
    • Cursor IDEでCrewプロジェクトをゼロから作成し、
      ディレクトリ構成や自動生成ファイルを確認。続いて、エージェントの定義をYAMLで行い
      「役割・目標・バックストーリー」の重要性を解説。
    • CrewAIを使った複数エージェント
      （ディベーターとジャッジに異なるLLMを割り当て）構成の
      ディベート・シナリオを構築するデモンストレーション

  • コンテンツ

Day2（Week3）

Day3（Week3）

Day4（Week3）

Day5（Week3）

  • 内容

    • AIチームの構築：協調開発のためのCrewAIの設定
    • 株式取引アプリを開発するための協調型AIエージェント開発を行う。
    • アプリを開発するためエージェント内でGPT-4oとClaudeのLLMを使用する。
    • 単一モジュールから完全なシステムへ：高度なCrewAIテクニック

  • 要約

    • さらにCrewに、リードに設計、バックエンドに実装、フロントエンドにUI作成、
      テストエンジニアに単体テストを割り当て。
    • 最後に、取引プラットフォーム用の口座管理・ポートフォリオ管理フレームワークを作る
      コーディングチャレンジを実行
    • UIやバックエンド・フロントエンドの連携がスムーズに動作した体験に非常に感動し、
      これを強調
    • CrewAIは多機能で便利だが、
      処理が隠蔽されているためデバッグが難しいというトレードオフがある。

  • コンテンツ

Week4

Day1（Week4）

  • 内容

    • LangGraph解説：堅牢なAIエージェントを実現するグラフベースアーキテクチャ
    • LangGraph解説：フレームワーク、Studio、Platformコンポーネントの比較
    • LangGraphの理論：高度なエージェントシステムを構築するためのコアコンポーネント

  • 要約

    • LangChain社は3つの製品を提供している：
      LangChain（最初期のLLMフレームワーク） / LangSmith（モニタリング） / LangGraph（エージェント）
    • 複雑なマルチエージェントワークフローを（ノード、エッジ、状態の）「グラフ」構造で設計、
      安定性（人間の関与）・回復性（メモリ、状態復元）・再現性を重視。
    • LangGraphの商用戦略として、
      Platformを前面に出して「LangGraph」と同一視して宣伝しているが、
      実際に学習対象となるのはフレームワーク部分
    • LangChain系は便利だが、抽象化が増えることで内部の仕組みが不透明になり、
      デバッグが難しくなる。使う場合も内部の動きを理解することが重要。
    • 構築の2フェーズと5ステップ：
      構築フェーズ（状態クラスを定義 / グラフビルダー起動 / ノード作成 / エッジ作成 /
      グラフをコンパイル）、実行フェーズ

Day2（Week4）

  • 内容

    • LangGraph深掘り：グラフベースのエージェントワークフローにおける状態管理
    • LangGraphをマスターする：状態オブジェクトの定義とリデューサーの使用方法
    • LangGraphの基礎：ノード、エッジ、ワークフローのステップバイステップ作成
    • LangGraphチュートリアル：グラフ構造を持つOpenAIチャットボットの構築

  • 要約

    • LangGraphは、状態を不変オブジェクトとして扱い、
      ノード関数とReducerによって安全に状態遷移を管理
    • 余談：Redux の Reducer と同じで、現在の state と 一連の Action の流れを通じ
      state を段階的に変化・集約。
    • 変数や戻り値に「意味付け」をするPythonの型ヒント（特にAnnotated）が
      Reducerを指定するために重要な役割を果たす。
    • ノードを作り、グラフに追加し、エッジで接続し、コンパイルしてGradioチャットで実行する
      一連の流れをランダム文章生成を例に紹介。

  • コンテンツ

Day3（Week4）

  • 内容

    • LangGraph上級チュートリアル：スーパーステップとチェックポイント機能の解説
    • LangSmithのセットアップとLangGraphアプリケーション用カスタムツールの作成
    • LangGraphのツール呼び出し：条件付きエッジとツールノードの操作
    • LangGraphのチェックポイント機能：会話間でメモリを維持する方法
    • SQLiteによる永続的AIメモリの構築：LangGraphの状態管理

  • 要約

    • スーパーステップの概念、状態管理とReducer、チェックポイント機能について説明

      • スーパーステップ：「グラフ全体の1回呼び出し」で並列実行ノードをまとめる。
      • 状態管理とReducer：同一スーパーステップの状態変化をReducerで結合する。
      • チェックポイント機能：各スーパーステップ終了後に状態を記録（凍結）

    • LangGraph上で、LangSmithの設定、LangChainの既製ツール利用、
      カスタムツール作成、ツール呼び出し方法

    • GradioのチャットボットとLangGraphのエージェント・ツール呼び出しを
      統合する手順と実行

    • チェックポイント機能により、独立した呼び出し間でも状態を保持・再現可能になり、
      任意の時点に戻って再実行できる。

    • メモリをSQLiteで永続化し、ツール呼び出しや会話の状態を保持、
      再起動や再利用時にも情報が維持されることを確認。

  • コンテンツ

Day4（Week4）

Day5（Week4）

  • 内容

    • エージェントAI：アシスタントにWeb検索、ファイルシステム、Python REPLを追加する
    • LangChainツール連携：強力なAIサイドキックをゼロから構築する
    • AIワークフローの作成：グラフビルダーとノード間通信技術
    • Gradioアプリで状態管理を使い、独立したユーザーセッションを作成する
    • AIフィードバックループの内部：AIがエラーを評価・修正する仕組みを見る
    • AIアシスタントのアップグレード：メモリ、明確化の質問、カスタムツール

  • 要約

    • Sidekickアプリに様々なツールを組み込み、より強力なAIエージェントとして機能させる
    • 機能：ウェブ検索、プッシュ通知送信、FSアクセス、Wikipedia参照、Pythonコード実行
      （注意：自由度が上がれば危険性も高まる）
    • ノートブックでのプロトタイピングを経て、モジュールとして本番環境で利用する。
    • 構成と調整（ワーカーのプロンプト → ルーティング → エバリュエーター設定 →
      グラフ管理（構築と実行）→ クリーンアップ）
    • Gradio での UI 操作はUIイベントハンドリングされ、
      Sidekickのエージェントのワークフローが呼び出され、そこで状態が管理される。
    • デモ：Sidekickが計算や情報収集、レポート作成、ファイル更新などを自律的に行い、
      評価フィードバックを取り込みながら正確にタスクを完遂
    • 課題：＝カスタマイズ、ポイントは「プロンプト、ツール追加、メモリやユーザー識別機能、
      エージェント権限とタスクの分散、意欲的に実験」など。

  • コンテンツ

Week5

Day1（Week5）

Day2（Week5）

  • 内容

    • 高度なAutoGen Agent Chat：マルチモーダル機能と構造化出力
    • AutoGenとLangChainでプライマリーエージェントと評価者エージェントを実装する
    • ヘッドレスWebスクレイピングチュートリアル：AutoGenでのMCPサーバーフェッチ連携

  • 要約

    • AutoGen Agent Chatでは、マルチモーダル会話が可能、構造化出力が容易、
      LangChainツールへのアクセスが可能
    • エージェント間でフィードバックを回すチーム形式で、
      より精度の高いアウトプットを生成可能だが
      無限ループや処理長時間化のリスクに注意する必要がある。
    • エージェントが脱線する問題は、よりインテリジェントな終了条件を設定することで防げる。
      ハードコードされたテキスト検索だけに頼るのは避ける。
    • MCP準拠のツールはAutoGenから簡単に利用可能。
      mcp_server_toolsで任意の処理をMCPクライアント対応のエージェントから
      使用できるようにMCPサーバから配信できる。

  • コンテンツ

Day3（Week5）

  • 内容

    • AutoGen Core：分散エージェント通信のバックボーン
    • AutoGen Coreでのエージェント通信：メッセージハンドラとディスパッチ
    • AutoGen Coreのエージェント登録とメッセージハンドリング：実践例
    • AutoGen Coreスタンドアロンエージェント：GPT-4oとLlamaでじゃんけん

  • 要約

    • AutoGen Core は、
      多様で分散した自律型エージェント同士のインタラクションを管理する基盤。

    • ライブラリ非依存でメッセージング機構とエージェント管理のみ提供、
      エージェント間の相互作用に焦点を置く。

    • 基本概念

      • 分離の原則：エージェントのロジック（実際の動作）とメッセージの配信方法、
        およびその相互作用を分離する。
      • フレームワークの役割：エージェントの作成・ライフサイクル管理、メッセージ通信

    • ランタイムの種類

      • スタンドアロン：ローカルマシンでシンプルに実行
      • 分散型：リモートのエージェント間で相互作用

    • AutoGen Coreが 「エージェント型の登録」「ID指定のメッセージルーティング」 を提供、
      実際の処理はエージェントの実装に委ねられる。

    • 「Hi there」→「You said 'Hi there' and I disagree」と回答するエージェントを組み合わせて、
      どのようになるかを示す簡単なデモ

    • 続いて「じゃんけんゲーム」を構築・実行し、
      AutoGenの本質は異なるエージェント同士が相互作用できる仕組みを
      提供することを説明

  • コンテンツ

Day4（Week5）

  • 内容

    • AutoGen Core分散ランタイム：アーキテクチャとコンポーネントの解説
    • AutoGen CoreとgRPCランタイムで分散AIエージェントを実装する
    • 分散エージェントシステムの構築：AutoGenのクロスプロセス通信

  • 要約

    • AutoGen Core の分散ランタイムはまだ実験的で、
      本番利用には早いが将来性がある仕組み。

    • 単一マシン上の処理ではなく、プロセスやマシンをまたいでメッセージングを行う。

    • 構成要素は2つ：エージェントをホストサービスに登録し、分散環境で利用可能にする。

      • ホスト・サービス：ワーカー・ランタイムを管理（セッション管理、メッセージ間通信）
      • ワーカー・ランタイム：実際にエージェントを保持しコードを実行

    • エージェント起動のコードを変えるだけで、
      エージェントの登録先ワーカー（プロセス）を変更できる。

      • 各エージェントを1つのワーカーに登録するか、別々のワーカーに登録するか変更できる。
      • ワーカーの実体はプロセスで、単一プロセスか？複数プロセス構成か？を
        起動コードで変更できる。
      • なお、スレッドは基本使わず、非同期（asyncio）で
        タスク並列処理がされる。

  • コンテンツ

Day5（Week5）

Week6

Day1（Week6）

  • 内容

    • モデルコンテキストプロトコル（MCP）入門：AnthropicのAIコネクタ
    • MCPアーキテクチャ解説：ホスト、クライアント、サーバーの理解
    • MCPサーバー・スタジオ：LLMを強力な外部ツールに接続する
    • MCPサーバーマーケットプレイス：OpenAIエージェントのための数千のツールへのアクセス

  • 要約

    • Anthropic社のModel Context Protocol (MCP) を中心に解説
      （MCP は Anthropic社 が提唱・開発したプロトコル）
    • 目的は、AIエージェントやLLMが
      外部のツールやデータソースと安全かつ標準化された方法でやり取りできるようにすること。
    • LLMエージェントと外部ツール（データベース、API、アプリケーションなど）を
      接続する仕組みとして設計されている。
    • MCPは大きく3つの要素で構成される（ホスト / クライアント / サーバー）。
      ホストがクライアントを使ってサーバからツールを取得。
    • 3つのアーキテクチャモデル
      （ローカル実行（テスト） / ローカル＋外部（実際） / リモートサーバー（レア））
    • よくある誤解、サーバーという言葉からサーバーで動作するものと考えがちだが、
      多くはローカル起点で動作。
    • 通信方式（トランスポート）：stdio：一般的だがリモートでは利用不可。
      SSE：HTTPSベースでリモートで利用可。
    • OpenAI Agents SDKにMCP（Model Context Protocol）が
      統合された最新機能を使ったデモ
    • MCPサーバーは、PlaywrightやWeb Storage、MCP Weather、Slack、GitHub、
      Blender接続など多数が公開されている。
    • MCPは、これら数千もの外部ツールを数行のコードで統合できる仕組みが
      シンプルながら強力。

  • コンテンツ

Day2（Week6）

  • 内容

    • MCPサーバーの作成方法：共有可能なツールコレクションの構築
    • 独自のMCPサーバーを構築：PythonコードからAIアクセス可能なツールへ
    • OpenAIでポートフォリオ管理のためのカスタムMCPツールを実装する
    • OpenAIとAnthropicのツール連携のためのMCPクライアントの実装方法
    • MCPアーキテクチャ：LLMエージェントツールのためのクライアント・サーバーシステムの構築

  • 要約
    MCPクライアントとサーバーを使ったツール実行の裏側を理解し、
    統一的にリソースを管理・共有できる仕組み を示し、演習を通して体験

    • MCPサーバーを開発する（作らない場合、Function Callingだけで事足りる）

      • Cursor IDEのラボで独自の MCP サーバーを作成し、
        Python モジュールをツールとして公開
      • クライアント実装 (accounts.py) とサーバー実装 (accounts_server.py) を
        分離して実装。
      • 口座名、残高、戦略、保有資産、取引リスト、ポートフォリオ価値の時系列データから
        株の売買やポートフォリオ計算を行う。
      • サーバーにデコレートされた関数
        （get_balance、get_holdings、buy_shares、sell_shares）が
        自動的にクライアントに公開される。

    • MCPクライアントを開発する
      （クライアントはありモノ実装を使えばいいが、ココでは、あえて自作）

      • クライアントを使用してMCPサーバーと通信、ツールやパラメーターを取得＆呼出。
      • 必要になるのは、独自アプリケーションで複数のMCPサーバーを呼び出す場合や、
        既存のSDKが利用できない場合。

  • コンテンツ

Day3（Week6）

  • 内容

    • MCPナレッジグラフサーバーでAIエージェントに永続メモリを追加する
    • MCPサーバーで Brave Search と Polygon.io をセットアップする
    • 金融データAPIのセットアップ：MCPサーバー接続のクローンと設定

  • 要約
    3つのアーキテクチャモデル（ローカル実行 / ローカル＋外部 / リモートサーバー）の実装

    • ローカル実行：ローカルストレージを使って、
      構造化された関係性ベースのメモリをエージェントに追加
    • ローカル実行：ローカルMCPサーバーで、Brave Searchのウェブ検索を利用
    • ローカル＋外部：Polygon.io のリモートMCPサーバーによる株価取得の試行

  • コンテンツ

Day4（Week6）

  • 内容

    • メモリ共有とWeb検索を備えたマルチエージェント取引システムの作成
    • エージェントの連携：OpenAI Agents SDKでリサーチャーをツールに変換する
    • ツールを使用する取引エージェント：株式市場リサーチのためのMCP実装
    • OpenAI Agents SDK：マルチエージェント取引システムモジュールの開発
    • 高度な手法：OpenAI Agents SDKでの取引関数の実装
    • 回復力のある取引エージェントの構築：金融AIシステムにおけるエラーハンドリング

  • 要約
    最終課題では、OpenAI Agents SDKとMCPを用いた
    自律型エージェント「Autonomous Polygon.io Agents」のシミュレーターを開発。

    • 金融市場を対象とした株式取引シミュレーションで、
      4人のトレーダーと1人のリサーチャーが、
      6つのMCPサーバーから16のツールやデータを取得して完全自律的に動作。
    • リサーチャー：オンライン検索ツール（Brave）を使用し
      市場調査やニュース収集など調査タスク担当に特化。MCPツールに変換される。
    • トレーダー：MCPツールのリサーチャーが提供する情報に基づき取引判断を行う。
      口座情報、メモリ共有、ウェブ取得、検索ツールを持ち、キャッシュ機能で効率化。
    • 先ずは、EdというトレーダーをリサーチャーMCPツールで初期化し、
      戦略に基づく意思決定・株取引を実行、トレースで活動全体を検証。
    • さらに、trade と rebalance という2つの主要タスクをエージェントに実行させ、
      自律的に株取引を行い、トレース様子を確認する。

  • コンテンツ

Day5（Week6）

  • 内容

    • 最終課題の集大成：AIトレーダーのためのプッシュ通知と戦略の進化
    • AI取引ダッシュボード：Gradioでポートフォリオのパフォーマンスを可視化する
    • エージェントAIエンジニアリング：コースの結論と実社会への応用

  • 要約

    • 複数の自律エージェントがシミュレーション取引環境で取引を行う
      Autonomous Polygon.io Agentsに機能を追加し完成させる。

    • 4人のトレーダー：ウォーレン（ファンダメンタル）、ジョージ（マクロ経済イベント）、
      レイ（マクロ経済サイクル）、キャシー（イノベーション）

    • トレーダー毎にLLMを変え、新しいMCPツールとして「戦略変更」「プッシュ通知」を
      追加して使用。

    • フロア（各トレーダーの取引やリバランスを実行）を追加し、GradioによるUIを実装する。

    • 重要なこと

      • 解決策ではなく、問題から始める
      • 成功を評価する指標を持つ
      • 最初は自律性よりもワークフローを優先する
      • トップダウンではなくボトムアップで作業する
      • シンプルに始め、それから追加していく
      • 大規模なフロンティアモデルから始め削減していく
      • メモリではなく実際のコンテキストを考慮
      • ほとんどの問題はプロンプトで解決する
      • トレースを見ること
      • 研究者になる。研究開発への近道はない。

  • コンテンツ

参考

Cursor

コード

スライド

（元 Wiki では未記載）

移行メモ

  • PukiWiki のページ内アンカ（#xxxxxxxx）は GitHub Wiki では再現できないため、

    • 同一ページ内のアンカは、見出しから生成されるアンカに張り替え、
    • 他ページのアンカを指すリンクは「〜（ページ名 の該当節を参照）」の形に置き換えた。

  • Week1〜Week6 に「Day1」〜「Day5」の見出しが重複し GitHub Wiki ではアンカが衝突するため、 「Day1（Week1）」のように括弧で週を補って一意にした（計 30 見出し）。

  • 元 Wiki の取り消し線（%%…%%）は <del> に置き換えた。

  • 元ページの誤記を修正した。 「明示的制御が必要とが確認された」→「明示的制御が必要であることが確認された」、 「実験的な試として」→「実験的な試みとして」、 「機能に付いて説明」→「機能について説明」、 「Magenta One」→「Magentic-One」、 「[OpenAI API]]を使った」→「OpenAI APIを使った」 （PukiWiki のリンク記法が壊れていた）。

  • Week3 Day4 の「5つのメモリタイプ」は、 実際に列挙されているのが 4 種類（長期・短期・実体・文脈）であるため 「4つのメモリタイプ」に修正した。

  • 「スライド」の節は元 Wiki が「...」のみで内容が無いため、その旨を注記した。

Tags: 移行, Udemy, エージェント, Agentic AI, OpenAI Agents SDK, CrewAI, LangGraph, AutoGen, MCP, Cursor

このWikiは「Open棟梁Project」,「OSSコンソーシアム 開発基盤部会」によって運営されています。

NetDevInfraWiki

マイクロソフト系技術情報 Wiki
Open 棟梁 Wiki

（未着手）

開発基盤部会 Wiki

移行管理: DONE ／ TODO

Clone this wiki locally