<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>設計パターン on hagizo.io</title><link>https://ha.gizwoo.com/tags/%E8%A8%AD%E8%A8%88%E3%83%91%E3%82%BF%E3%83%BC%E3%83%B3/</link><description>Recent content in 設計パターン on hagizo.io</description><generator>Hugo -- gohugo.io</generator><language>en</language><lastBuildDate>Wed, 20 May 2026 20:31:12 +0900</lastBuildDate><atom:link href="https://ha.gizwoo.com/tags/%E8%A8%AD%E8%A8%88%E3%83%91%E3%82%BF%E3%83%BC%E3%83%B3/index.xml" rel="self" type="application/rss+xml"/><item><title>【AI開発】エージェントAI設計パターンを4レイヤで整理する</title><link>https://ha.gizwoo.com/agent-ai-pattern-layers-q9vlm2rta6/</link><pubDate>Wed, 22 Apr 2026 01:19:00 +0900</pubDate><guid>https://ha.gizwoo.com/agent-ai-pattern-layers-q9vlm2rta6/</guid><description>&lt;p&gt;前回は、エージェントAIの基本パターンとして ReAct、Reflection、Planning、Multi-Agent をざっくり整理しました。今回はもう一歩踏み込み、実装時に「どの責務をどの層に置くか」という視点で、設計パターンを4つのレイヤに分けて考えます。&lt;/p&gt;
&lt;h2 id="1-ゴールと計画のレイヤ"&gt;1. ゴールと計画のレイヤ
&lt;/h2&gt;&lt;p&gt;最初に切り出すべきなのは、ユーザーの曖昧な依頼を実行可能なタスクへ変換する層です。DeepSquareの記事では、Passive Goal Creator と Proactive Goal Creator が、目標設定と計画生成のパターンとして紹介されています。&lt;a class="link" href="https://deepsquare.jp/2025/04/ai-agent-design-pattarn/" target="_blank" rel="noopener"
 &gt;Yue Liu氏らのAIエージェントデザインパターン解説&lt;/a&gt; では、ユーザーの明示的な指示を対話で明確化する方式と、コンテキストからエージェント側が目標を提案する方式が整理されています。&lt;/p&gt;
&lt;p&gt;開発者視点では、この層は「タスク定義器」です。入力は自然言語でも、出力は &lt;code&gt;goal&lt;/code&gt;、&lt;code&gt;constraints&lt;/code&gt;、&lt;code&gt;success_criteria&lt;/code&gt;、&lt;code&gt;allowed_tools&lt;/code&gt; のような構造化データにしておくと、後続の実行層が安定します。&lt;/p&gt;
&lt;p&gt;計画生成では、Plan &amp;amp; Execute、Single-path Plan Generator、Multi-path Plan Generator を使い分けます。Google Cloudのガイドも、パターン選定ではタスクの複雑さ、レイテンシ、費用、人間の関与を評価すると説明しています。&lt;a class="link" href="https://docs.cloud.google.com/architecture/choose-design-pattern-agentic-ai-system?hl=ja" target="_blank" rel="noopener"
 &gt;Google Cloudの設計パターン比較&lt;/a&gt; 単純なCRUDならSingle-pathで十分ですが、仕様策定や技術調査のように正解が一つでないタスクでは、複数案を出して比較する価値があります。&lt;/p&gt;
&lt;h2 id="2-推論と自己改善のレイヤ"&gt;2. 推論と自己改善のレイヤ
&lt;/h2&gt;&lt;p&gt;次の層は、計画を実際の推論と行動に落とし込む部分です。Anthropicの設計ガイドを要約した記事では、Prompt Chaining、Routing、Parallelization、Orchestrator-Workers、Evaluator-Optimizer といったワークフローが紹介されています。&lt;a class="link" href="https://blog.scuti.jp/effective-ai-agent-design-2024-guide/" target="_blank" rel="noopener"
 &gt;効果的なAIエージェント設計方法&lt;/a&gt; の整理を見ると、いきなり自律エージェントにするより、まず工程を分けて安定させるのが現実的です。&lt;/p&gt;
&lt;p&gt;Prompt Chainingは「要件整理、設計、実装、テスト」のようにフェーズを分けるパターンです。ReActは、思考、ツール実行、観察を繰り返すループです。実装では、1回のLLM呼び出しにすべてを詰めるより、状態を短く保ち、各ステップでツール結果を観察させるほうが失敗を回収しやすくなります。&lt;/p&gt;
&lt;p&gt;品質を上げたい場合は、Self-Reflective または Evaluator-Optimizer を足します。Qiitaの設計パターン整理では、Self-Reflectiveは軽量な自己内省、Evaluator-Optimizerは生成と評価を分離するループとして扱われています。&lt;a class="link" href="https://qiita.com/nogataka/items/efda480d2d91d04707c8" target="_blank" rel="noopener"
 &gt;AIエージェント デザインパターン完全ガイド&lt;/a&gt; コード生成ならテスト、文章生成ならチェックリスト、調査なら出典の網羅性を評価軸にすると、単なる「もう一回考えて」よりも効果が出ます。&lt;/p&gt;
&lt;h2 id="3-協調のレイヤ"&gt;3. 協調のレイヤ
&lt;/h2&gt;&lt;p&gt;単一エージェントが大きくなりすぎたら、協調レイヤを導入します。Orchestrator-Workersは、中央のオーケストレータがタスクを分解し、調査、実装、レビューなどのワーカーに渡す構成です。Weights &amp;amp; Biases Japanの記事では、Planning と Multi-Agent Collaboration の組み合わせが、論文調査や分析、執筆のような複雑タスクに向く例として説明されています。&lt;a class="link" href="https://note.com/wandb_jp/n/n27b7ca276a99" target="_blank" rel="noopener"
 &gt;AIエージェントのデザインパターン&lt;/a&gt;&lt;/p&gt;
&lt;p&gt;協調パターンには、役割ベース、投票ベース、討論ベースがあります。役割ベースはソフトウェア開発と相性がよく、プランナー、実装者、レビューアを分けるだけでも責務が明確になります。投票ベースは不確実な分類や候補選定に向き、討論ベースは戦略判断のように反論が価値を持つ場面で使います。&lt;/p&gt;
&lt;p&gt;ただし、マルチエージェントは万能ではありません。共有状態、書き込み権限、失敗時のリトライ、最終判断者を決めないまま導入すると、単一エージェントよりデバッグが難しくなります。まず単一エージェント＋ツールで詰まりを見つけ、明確なボトルネックが出たところだけ分割するのが安全です。&lt;/p&gt;
&lt;h2 id="4-入出力と安全性ガードのレイヤ"&gt;4. 入出力と安全性ガードのレイヤ
&lt;/h2&gt;&lt;p&gt;最後の層は、入出力と安全性を制御する部分です。Zennの記事では、最小構成から始めること、マルチレイヤのガードレール、人間の介入、ツール定義の標準化が強調されています。&lt;a class="link" href="https://zenn.dev/dxclab/articles/808efaaa7db736" target="_blank" rel="noopener"
 &gt;失敗しないAIエージェント設計&lt;/a&gt;&lt;/p&gt;
&lt;p&gt;Guardrailsは、プロンプト、ツール呼び出し、最終出力をチェックする仕組みです。社内API、個人情報、削除や送信のような不可逆操作を扱うなら、ルールベースの検証、人間承認、操作ログを必ず入れます。&lt;/p&gt;
&lt;p&gt;Agent Adapterも重要です。LLMから見るツールインターフェイスを統一しておくと、裏側のAPIやモデルを差し替えてもワークフロー全体を壊しにくくなります。引数名、入力形式、失敗時の戻り値、権限境界まで含めて設計することで、ツール誤用を減らせます。&lt;/p&gt;
&lt;h2 id="実装時の最小構成"&gt;実装時の最小構成
&lt;/h2&gt;&lt;p&gt;実務で始めるなら、最初の構成は大きくしすぎないほうがよいです。おすすめは、ゴール定義器、Plan &amp;amp; Execute、ReAct風ツールループ、軽いEvaluator、Guardrails、Adapterの組み合わせです。&lt;/p&gt;
&lt;p&gt;たとえばDevOps自動化なら、まずユーザー依頼を「対象サービス、環境、許可された操作、成功条件」に正規化します。次に、調査、変更案作成、確認、実行、検証というPlanを作ります。各ステップではログ検索、CI確認、設定ファイル編集などのツールを呼び、最後にEvaluatorが「本当に成功条件を満たしたか」を確認します。デプロイや削除のような操作だけはHuman-in-the-Loopで止めます。&lt;/p&gt;
&lt;p&gt;このように見ると、エージェントAIの設計パターンは流行語ではなく、責務分離のための部品です。ゴール、推論、協調、安全性を別々に設計しておくと、最初は単一エージェントでも、あとからマルチエージェントや評価基盤へ拡張しやすくなります。&lt;/p&gt;</description></item><item><title>【AI開発】エージェントAIの設計パターン入門</title><link>https://ha.gizwoo.com/agent-ai-design-patterns-k7mqa4nzp2/</link><pubDate>Wed, 22 Apr 2026 01:10:00 +0900</pubDate><guid>https://ha.gizwoo.com/agent-ai-design-patterns-k7mqa4nzp2/</guid><description>&lt;p&gt;LLMを単発のチャットとして使う段階から一歩進むと、外部ツールを呼び出し、結果を観察し、必要なら計画を修正する「エージェントAI」の設計が重要になります。この記事では、実装時に迷いやすい代表的な設計パターンを、個人開発や業務自動化に使いやすい形で整理します。&lt;/p&gt;
&lt;h2 id="まずは拡張llmから始める"&gt;まずは拡張LLMから始める
&lt;/h2&gt;&lt;p&gt;Anthropicは、エージェントシステムの基本部品を「検索、ツール、メモリで拡張されたLLM」と整理しています。&lt;a class="link" href="https://www.anthropic.com/research/building-effective-agents" target="_blank" rel="noopener"
 &gt;Building effective agents&lt;/a&gt; でも、いきなり複雑なフレームワークに入るより、まずはシンプルなLLM呼び出し、RAG、明確なツール定義から始めることが推奨されています。&lt;/p&gt;
&lt;p&gt;重要なのは、AIに何でも自由にやらせることではなく、観察できる環境を渡すことです。たとえばコード生成ならテスト実行、調査なら検索結果、運用自動化ならAPIレスポンスが「現実からのフィードバック」になります。&lt;/p&gt;
&lt;h2 id="基本パターン"&gt;基本パターン
&lt;/h2&gt;&lt;h3 id="react-考えて動いて観察する"&gt;ReAct: 考えて、動いて、観察する
&lt;/h3&gt;&lt;p&gt;ReActは Reasoning and Acting の略で、思考、行動、観察を繰り返すパターンです。&lt;a class="link" href="https://machinelearningmastery.com/the-roadmap-to-mastering-agentic-ai-design-patterns/" target="_blank" rel="noopener"
 &gt;Machine Learning Masteryの記事&lt;/a&gt; では、複雑で手順が固定しづらいタスクの出発点として紹介されています。&lt;/p&gt;
&lt;p&gt;このパターンは、調査、デバッグ、問い合わせ対応のように「次に何をすべきか」が途中結果で変わるタスクに向いています。一方、入力と出力が安定している処理なら、普通のワークフローで十分です。&lt;/p&gt;
&lt;h3 id="reflection-出力を批評して直す"&gt;Reflection: 出力を批評して直す
&lt;/h3&gt;&lt;p&gt;Reflectionは、生成、批評、修正を回す品質改善パターンです。Andrew Ng氏も、エージェント的ワークフローの代表例として Reflection、Tool use、Planning、Multi-agent collaboration を挙げています。&lt;a class="link" href="https://www.linkedin.com/posts/andrewyng_one-agent-for-many-worlds-cross-species-activity-7179159130325078016-_oXr" target="_blank" rel="noopener"
 &gt;Andrew Ng氏の投稿&lt;/a&gt; では、コードや文章を生成した後に別プロンプトで批評し、改善版を作る流れが説明されています。&lt;/p&gt;
&lt;p&gt;ただし、Reflectionはコストと待ち時間を増やします。常に入れるのではなく、記事、コード、契約書レビューのように品質基準を定義しやすい場面で使うのがよさそうです。&lt;/p&gt;
&lt;h2 id="複雑さを足すタイミング"&gt;複雑さを足すタイミング
&lt;/h2&gt;&lt;h3 id="planning-先に分解する"&gt;Planning: 先に分解する
&lt;/h3&gt;&lt;p&gt;Planningは、目的をサブタスクに分解してから実行するパターンです。複数システムを順番に操作する処理、長い調査、実装からテストまで含む開発タスクでは、最初に依存関係を見える化すると失敗しにくくなります。&lt;/p&gt;
&lt;h3 id="multi-agent-専門家を分ける"&gt;Multi-Agent: 専門家を分ける
&lt;/h3&gt;&lt;p&gt;Multi-Agentは、調査担当、実装担当、レビュー担当のように役割を分けるパターンです。Anthropicの資料では、単一エージェント、マルチエージェント、ワークフロー型の使い分けが重要だとされています。&lt;a class="link" href="https://resources.anthropic.com/building-effective-ai-agents" target="_blank" rel="noopener"
 &gt;Building Effective AI Agents&lt;/a&gt; のような実践資料でも、複雑さとビジネス価値を釣り合わせる視点が強調されています。&lt;/p&gt;
&lt;p&gt;ただし、最初からマルチエージェントにすると、責任範囲、共有状態、ルーティング、結果の統合が難しくなります。まず単一エージェントで詰まりを確認し、明確なボトルネックが見えたら分割するくらいが現実的です。&lt;/p&gt;
&lt;h2 id="まとめ"&gt;まとめ
&lt;/h2&gt;&lt;p&gt;エージェントAI設計のコツは、最初から自律性を最大化しないことです。拡張LLM、ReAct、Reflection、Planning、Multi-Agentの順に、必要な複雑さだけを足していくと、デバッグしやすく安全なシステムになります。特に本番運用では、停止条件、人間の承認ポイント、ツールの権限境界を設計に含めることが大切です。&lt;/p&gt;</description></item></channel></rss>