📜 要約
主題と目的
本調査は、GitHub上のHumanLayerプロジェクトおよびHacker Newsで言及されている「12-Factor Agents」に着目し、LLM（大規模言語モデル）を活用したアプリケーションの信頼性向上を目的として、その基本原則と実践手法を整理・分析するものです。
具体的には、従来のソフトウェア開発手法（例：DAGによるオーケストレーションなど）と比較しながら、LLMエージェント特有の課題（コンテキストウィンドウの過大、意思決定の複雑性、エラー処理の自動化など）にどのように対処すべきか、そしてそのために提示される12の原則（Factor 1～Factor 12）を通じ、以下の点を明確にすることを目的としています。
具体的には、従来のソフトウェア開発手法（例：DAGによるオーケストレーションなど）と比較しながら、LLMエージェント特有の課題（コンテキストウィンドウの過大、意思決定の複雑性、エラー処理の自動化など）にどのように対処すべきか、そしてそのために提示される12の原則（Factor 1～Factor 12）を通じ、以下の点を明確にすることを目的としています。
• LLMエージェントの設計において、シンプルかつ高信頼性なシステムを実現するための考え方
• エージェントの規模を小さく、焦点を絞ることの重要性（Factor 10）
• プロンプト管理、コンテキストウィンドウ最適化、エラー情報の集約といった具体的手法の提示
• エージェントの規模を小さく、焦点を絞ることの重要性（Factor 10）
• プロンプト管理、コンテキストウィンドウ最適化、エラー情報の集約といった具体的手法の提示
回答
調査結果から得られた情報を基に、ユーザーの調査依頼に対する回答は以下の通りです。
-
12-Factor Agentsの全体像
- LLMベースのアプリケーションを実運用する際、従来のアプリケーション設計原則（Herokuの12-Factor Appsなど）を拡張し、LLM固有の課題に対応するための新たな指針として提案されています。
- このフレームワークは、ツール呼び出しの構造化、実行状態とビジネス状態の統一、そしてエラー処理の自動化など、多角的な観点からシステムの信頼性向上を狙っています。
-
主要な原則の概要
以下の表は、12-Factor Agentsの各原則とその要点をまとめたものです。Factor番号 原則の名称・内容 主な利点・ポイント Factor 1 自然言語からツール呼び出しへ 自然言語を構造化したAPI呼び出しに変換し、自動化と正確性を向上 Factor 2 プロンプトの管理 プロンプトをコードで直接管理し、透明性と再現性を確保 Factor 3 コンテキストウィンドウを管理 過剰な情報量を避け、最適なトークン効率とパフォーマンスを確保 Factor 4 ツールは構造化された出力である 決定論的なコードトリガーにより、エラー発生を低減 Factor 5 実行状態とビジネス状態の統合 シンプルな状態管理により、デバッグや復旧が容易になる Factor 6 シンプルなAPIで起動／一時停止／再開 操作性を高め、複雑なタスクの管理や中断・再開が容易 Factor 7 ツール呼び出しで人間と連携する 人間のフィードバックを取り入れ、タスク実行の柔軟性を向上 Factor 8 制御フローを管理する 独自のコントロールフローにより、タスクの流れを柔軟にカスタマイズ Factor 9 エラーをコンテキストに集約する エラーメッセージやスタックトレースを活用し、自己修復能力を向上 Factor 10 小さく、焦点を絞ったエージェント 特定タスクに専念する小規模エージェントが信頼性と可観測性を向上 Factor 11 ユーザーがいる場所で対応する ユーザーが利用する複数のチャネル（Slack、メール、SMS等）に対応 Factor 12 エージェントをステートレスなリデューサーにする 状態管理の複雑さを低減し、予測可能性とデバッグの容易性を実現 -
具体例と実装手法
- 例として、自然言語をJSON形式に変換しツール呼び出しを実現するコードスニペットが示されています。これにより、LLMが誤った判断をするリスクを低減し、API呼び出しの精度向上が期待されます。
- Rustなどのプログラミング言語でプロンプト管理を直接実装する手法や、コンテキストエンジニアリングのためのカスタム形式の提案など、実装に直結する具体的な方法論も詳細に説明されています。
-
LLM応用における重要ポイント
- コンテキスト管理: 過去の状態やツール呼び出し結果などの情報を効率的に活用することで、LLMの出力精度を向上。
- エージェント分割: 複雑なモノリシックな設計を避け、各エージェントが明確な役割を持つことで、全体の信頼性および保守性を高める。
- 人間との連携: 自動化と同時に人間のフィードバックを取り入れることで、予期しない状況への柔軟な対応が可能。
結果と結論
調査結果から得られる主な結論は以下の通りです。
• 12-Factor Agentsは、LLMを組み込んだアプリケーションの信頼性・スケーラビリティ・保守性を向上させるための有効な設計指針である。
• 小規模で焦点を絞ったエージェント設計（Factor 10）は、コンテキストの管理やエラー処理の効率化において特に重要であり、実運用における品質向上に大きく寄与する。
• プロンプト管理、コンテキストウィンドウの最適化、実行状態とビジネス状態の統合など、具体的な手法や実装例を通じ、従来のソフトウェア開発のベストプラクティスをLLMエージェントに応用することが可能である。
• 今後、AI技術の急速な進化に対応するため、12-Factor Agentsの原則自体も柔軟に進化させ、コミュニティでの知見共有・議論を深めることが求められる。
• 小規模で焦点を絞ったエージェント設計（Factor 10）は、コンテキストの管理やエラー処理の効率化において特に重要であり、実運用における品質向上に大きく寄与する。
• プロンプト管理、コンテキストウィンドウの最適化、実行状態とビジネス状態の統合など、具体的な手法や実装例を通じ、従来のソフトウェア開発のベストプラクティスをLLMエージェントに応用することが可能である。
• 今後、AI技術の急速な進化に対応するため、12-Factor Agentsの原則自体も柔軟に進化させ、コミュニティでの知見共有・議論を深めることが求められる。
以上の観点により、LLMアプリケーションの実装における具体的な課題が明確になり、今後の取り組みとして、これらの原則を段階的かつ体系的に実装することで、より信頼性の高いシステム構築が実現できると結論付けられます。
コード実行
<!DOCTYPE html>
<html lang="ja">
<head>
<meta charset="UTF-8">
<meta name="viewport" content="width=device-width, initial-scale=1.0">
<title>12-Factor Agents: LLMアプリケーションの構築パターン</title>
<script src="https://unpkg.com/mermaid@11.4.0/dist/mermaid.min.js"></script>
<style>
body {
font-family: 'Segoe UI', Tahoma, Geneva, Verdana, sans-serif;
line-height: 1.6;
color: #333;
max-width: 1200px;
margin: 0 auto;
padding: 20px;
background-color: #f8f9fa;
}
.container {
background-color: white;
border-radius: 8px;
box-shadow: 0 4px 6px rgba(0, 0, 0, 0.1);
padding: 30px;
margin-bottom: 30px;
}
h1, h2, h3 {
color: #2c3e50;
}
h1 {
text-align: center;
margin-bottom: 30px;
padding-bottom: 15px;
border-bottom: 2px solid #3498db;
}
h2 {
margin-top: 30px;
padding-bottom: 10px;
border-bottom: 1px solid #eee;
}
.card {
background-color: #fff;
border-radius: 8px;
box-shadow: 0 2px 4px rgba(0, 0, 0, 0.1);
padding: 20px;
margin-bottom: 20px;
transition: transform 0.3s ease;
}
.card:hover {
transform: translateY(-5px);
box-shadow: 0 4px 8px rgba(0, 0, 0, 0.15);
}
.card-title {
font-weight: bold;
color: #3498db;
margin-top: 0;
margin-bottom: 15px;
}
.card-content {
margin-bottom: 0;
}
.mermaid {
margin: 30px auto;
text-align: center;
}
.source {
font-size: 0.8em;
color: #666;
text-align: right;
margin-top: 10px;
}
.grid {
display: grid;
grid-template-columns: repeat(auto-fill, minmax(300px, 1fr));
gap: 20px;
margin: 30px 0;
}
.highlight {
background-color: #f1f8ff;
border-left: 4px solid #3498db;
padding: 15px;
margin: 20px 0;
}
code {
background-color: #f5f5f5;
padding: 2px 5px;
border-radius: 3px;
font-family: monospace;
}
pre {
background-color: #f5f5f5;
padding: 15px;
border-radius: 5px;
overflow-x: auto;
font-family: monospace;
}
.tag {
display: inline-block;
background-color: #e1f5fe;
color: #0288d1;
padding: 3px 8px;
border-radius: 4px;
font-size: 0.8em;
margin-right: 5px;
margin-bottom: 5px;
}
.separator {
height: 1px;
background-color: #eee;
margin: 30px 0;
}
.link {
color: #3498db;
text-decoration: none;
}
.link:hover {
text-decoration: underline;
}
</style>
</head>
<body>
<div class="container">
<h1>12-Factor Agents: LLMアプリケーションの構築パターン</h1>
<div class="highlight">
<p>12-Factor Agentsは、大規模言語モデル（LLM）を活用したソフトウェアを本番環境で信頼性高く構築するための原則です。Herokuの「12-Factor Apps」に触発されたもので、LLMアプリケーションをより信頼性が高く、スケーラブルで、保守しやすいものにするためのエンジニアリングプラクティスに焦点を当てています。</p>
</div>
<!-- 概要図 -->
<h2>12-Factor Agentsの全体像</h2>
<div class="mermaid">
graph TD
title["12-Factor Agents"]
title --> F1["1. 自然言語からツール呼び出しへ"]
title --> F2["2. プロンプトを管理する"]
title --> F3["3. コンテキストウィンドウを管理する"]
title --> F4["4. ツールは構造化された出力である"]
title --> F5["5. 実行状態とビジネス状態を統合する"]
title --> F6["6. シンプルなAPIで起動/一時停止/再開"]
title --> F7["7. ツール呼び出しで人間と連携する"]
title --> F8["8. 制御フローを管理する"]
title --> F9["9. エラーをコンテキストに集約する"]
title --> F10["10. 小さく、焦点を絞ったエージェント"]
title --> F11["11. ユーザーがいる場所で対応する"]
title --> F12["12. エージェントをステートレスなリデューサーにする"]
classDef default fill:#f9f9f9,stroke:#333,stroke-width:1px;
classDef title fill:#3498db,stroke:#333,stroke-width:1px,color:white;
class title title;
</div>
<p class="source">出典: <a href="https://github.com/humanlayer/12-factor-agents/tree/main" target="_blank" rel="noopener noreferrer" class="link">GitHub - humanlayer/12-factor-agents</a></p>
<!-- 12の要素の詳細 -->
<h2>12の要素の詳細</h2>
<div class="grid">
<div class="card">
<h3 class="card-title">1. 自然言語からツール呼び出しへ</h3>
<p class="card-content">自然言語を構造化されたツール呼び出しに変換します。例えば、「2月のAIティンカーズミートアップのスポンサーとしてTerriに750ドルの支払いリンクを作成できますか？」という自然言語を、Stripe API呼び出しを記述する構造化オブジェクトに変換します。</p>
<div class="tag">変換</div>
<div class="tag">構造化</div>
</div>
<div class="card">
<h3 class="card-title">2. プロンプトを管理する</h3>
<p class="card-content">フレームワークに依存せず、プロンプトを直接管理することで、柔軟な開発を可能にします。プロンプトをコードとして直接管理することで、より柔軟な開発が可能になります。</p>
<div class="tag">プロンプト</div>
<div class="tag">制御</div>
</div>
<div class="card">
<h3 class="card-title">3. コンテキストウィンドウを管理する</h3>
<p class="card-content">LLMエージェントへの最適なインプットを提供するために、コンテキストエンジニアリングを行い、情報の密度、エラー処理、安全性、柔軟性、トークン効率を高めます。</p>
<div class="tag">コンテキスト</div>
<div class="tag">最適化</div>
</div>
<div class="card">
<h3 class="card-title">4. ツールは構造化された出力である</h3>
<p class="card-content">ツールをLLMからの構造化された出力として捉え、決定論的なコードをトリガーします。LLMの意思決定とアプリケーションのアクションの間に明確な分離を生み出します。</p>
<div class="tag">構造化</div>
<div class="tag">分離</div>
</div>
<div class="card">
<h3 class="card-title">5. 実行状態とビジネス状態を統合する</h3>
<p class="card-content">AIアプリケーションにおいて、実行状態とビジネス状態を統一することで、シンプルさ、シリアライズの容易さ、デバッグの容易さ、柔軟性、復旧の容易さ、分岐の容易さ、人間インターフェースと可観測性を向上させます。</p>
<div class="tag">状態管理</div>
<div class="tag">統合</div>
</div>
<div class="card">
<h3 class="card-title">6. シンプルなAPIで起動/一時停止/再開</h3>
<p class="card-content">エージェントのライフサイクル管理を容易にし、長時間実行される操作に対応するために、シンプルなAPIを通じてエージェントを起動、一時停止、再開できるようにします。</p>
<div class="tag">ライフサイクル</div>
<div class="tag">API</div>
</div>
<div class="card">
<h3 class="card-title">7. ツール呼び出しで人間と連携する</h3>
<p class="card-content">LLMがJSON形式で出力し、自然言語トークンで意図を宣言することで、人間との連携を可能にします。これにより、エージェントワークフローを従来のChatGPTスタイルのインターフェースの外で有効にします。</p>
<div class="tag">人間連携</div>
<div class="tag">インターフェース</div>
</div>
<div class="card">
<h3 class="card-title">8. 制御フローを管理する</h3>
<p class="card-content">独自の制御フローを持つことで、特定のユースケースに合わせた機能拡張や制御を可能にします。ツールの呼び出し結果の要約やキャッシュ、構造化された出力に対するLLMの判断などが可能になります。</p>
<div class="tag">制御フロー</div>
<div class="tag">カスタマイズ</div>
</div>
<div class="card">
<h3 class="card-title">9. エラーをコンテキストに集約する</h3>
<p class="card-content">エラー情報をコンテキストウィンドウに追加し、再試行することで、エージェントがエラーから学習し、タスクを完了する能力を高めます。これにより、エージェントは自己修復能力を獲得します。</p>
<div class="tag">エラー処理</div>
<div class="tag">自己修復</div>
</div>
<div class="card">
<h3 class="card-title">10. 小さく、焦点を絞ったエージェント</h3>
<p class="card-content">特定のタスクに特化した小規模で集中的なエージェントを構築することで、コンテキストウィンドウを管理しやすくし、LLMのパフォーマンスを高く維持します。</p>
<div class="tag">集中</div>
<div class="tag">特化</div>
</div>
<div class="card">
<h3 class="card-title">11. ユーザーがいる場所で対応する</h3>
<p class="card-content">ユーザーが普段利用するチャネル（Slack、メール、SMSなど）からエージェントをトリガーできるようにし、同じチャネルを介して応答できるようにすることで、AIアプリケーションをデジタルな同僚のように感じさせます。</p>
<div class="tag">ユーザー体験</div>
<div class="tag">チャネル統合</div>
</div>
<div class="card">
<h3 class="card-title">12. エージェントをステートレスなリデューサーにする</h3>
<p class="card-content">エージェントをステートレスに保つことで、システムの複雑さを軽減し、予測可能性を高めます。関数型プログラミングの概念に基づき、入力と状態を受け取り、新しい状態を返す純粋な関数として機能します。</p>
<div class="tag">ステートレス</div>
<div class="tag">予測可能性</div>
</div>
</div>
<!-- エージェントの進化 -->
<h2>ソフトウェア開発の変遷とエージェントの進化</h2>
<div class="mermaid">
flowchart TD
subgraph "60年前"
DG[有向グラフ\nフローチャートによる視覚化]
end
subgraph "20年前"
DAG[DAGオーケストレーター\nAirflow, Prefect, Dagster等]
end
subgraph "10-15年前"
ML[機械学習モデルがDAGに組み込まれる\nテキスト要約や感情分析]
end
subgraph "現在"
AGENT[LLMエージェント\n目標と遷移のセットを与え\nリアルタイムで意思決定]
end
DG --> DAG
DAG --> ML
ML --> AGENT
classDef default fill:#f9f9f9,stroke:#333,stroke-width:1px;
classDef current fill:#e1f5fe,stroke:#0288d1,stroke-width:2px;
class AGENT current;
</div>
<p class="source">出典: <a href="https://github.com/humanlayer/12-factor-agents/blob/main/content/brief-history-of-software.md" target="_blank" rel="noopener noreferrer" class="link">How We Got Here: A Brief History of Software</a></p>
<!-- エージェントループの図 -->
<h2>エージェントループの仕組み</h2>
<div class="mermaid">
flowchart LR
A[LLMが次のステップを決定\n構造化JSONを出力] --> B[決定論的コードが\nツール呼び出しを実行]
B --> C[結果がコンテキスト\nウィンドウに追加]
C --> A
classDef default fill:#f9f9f9,stroke:#333,stroke-width:1px;
</div>
<p class="source">出典: <a href="https://github.com/humanlayer/12-factor-agents/blob/main/content/brief-history-of-software.md" target="_blank" rel="noopener noreferrer" class="link">How We Got Here: A Brief History of Software</a></p>
<!-- マイクロエージェントの例 -->
<h2>マイクロエージェントの実装例: デプロイボット</h2>
<div class="mermaid">
sequenceDiagram
participant 人間
participant 決定的コード
participant エージェント
人間->>決定的コード: GitHubのメインブランチにPRをマージ
決定的コード->>決定的コード: ステージング環境にデプロイ
決定的コード->>決定的コード: ステージングに対してe2eテスト実行
決定的コード->>エージェント: 本番環境へのデプロイのために引き継ぎ
Note over エージェント: 初期コンテキスト: "SHA 4af9ec0を本番環境にデプロイする"
エージェント->>決定的コード: deploy_frontend_to_prod(4af9ec0)を呼び出し
決定的コード->>人間: 承認を要求
人間->>決定的コード: "最初にバックエンドをデプロイできますか？"と拒否
決定的コード->>エージェント: フィードバックを伝達
エージェント->>決定的コード: deploy_backend_to_prod(4af9ec0)を呼び出し
決定的コード->>人間: 承認を要求
人間->>決定的コード: 承認
決定的コード->>決定的コード: バックエンドのデプロイを実行
エージェント->>決定的コード: deploy_frontend_to_prod(4af9ec0)を呼び出し
決定的コード->>人間: 承認を要求
人間->>決定的コード: 承認
決定的コード->>決定的コード: フロントエンドのデプロイを実行
エージェント->>決定的コード: タスク完了を通知
決定的コード->>決定的コード: 本番環境に対してe2eテスト実行
</div>
<p class="source">出典: <a href="https://github.com/humanlayer/12-factor-agents/blob/main/content/brief-history-of-software.md" target="_blank" rel="noopener noreferrer" class="link">How We Got Here: A Brief History of Software</a></p>
<!-- 自然言語からツール呼び出しへの変換例 -->
<h2>自然言語からツール呼び出しへの変換例</h2>
<div class="highlight">
<p><strong>自然言語:</strong> 「2月のAIティンカーズミートアップのスポンサーとしてTerriに750ドルの支払いリンクを作成できますか？」</p>
<pre><code>{
"function": {
"name": "create_payment_link",
"parameters": {
"amount": 750,
"customer": "cust_128934ddasf9",
"product": "prod_8675309",
"price": "prc_09874329fds",
"quantity": 1,
"memo": "Hey Jeff - see below for the payment link for the february ai tinkerers meetup"
}
}
}</code></pre>
</div>
<p class="source">出典: <a href="https://github.com/humanlayer/12-factor-agents/blob/main/content/factor-1-natural-language-to-tool-calls.md" target="_blank" rel="noopener noreferrer" class="link">Factor 1: Natural Language to Tool Calls</a></p>
<!-- コンテキストウィンドウの例 -->
<h2>カスタムコンテキスト形式の例</h2>
<pre><code>[
{
"role": "system",
"content": "You are a helpful assistant..."
},
{
"role": "user",
"content": |
Here's everything that happened so far:
<slack_message>
From: @alex
Channel: #deployments
Text: Can you deploy the backend?
</slack_message>
<list_git_tags>
intent: "list_git_tags"
</list_git_tags>
<list_git_tags_result>
tags:
- name: "v1.2.3"
commit: "abc123"
date: "2024-03-15T10:00:00Z"
- name: "v1.2.2"
commit: "def456"
date: "2024-03-14T15:30:00Z"
- name: "v1.2.1"
commit: "ghi789"
date: "2024-03-13T09:15:00Z"
</list_git_tags_result>
what's the next step?
}
]</code></pre>
<p class="source">出典: <a href="https://github.com/humanlayer/12-factor-agents/blob/main/content/factor-3-own-your-context-window.md" target="_blank" rel="noopener noreferrer" class="link">Factor 3: Own your context window</a></p>
<!-- 人間との連携例 -->
<h2>ツール呼び出しによる人間との連携例</h2>
<pre><code>class Options {
urgency: Literal["low", "medium", "high"]
format: Literal["free_text", "yes_no", "multiple_choice"]
choices: List[str]
}
// Tool definition for human interaction
class RequestHumanInput {
intent: "request_human_input"
question: str
context: str
options: Options
}</code></pre>
<p class="source">出典: <a href="https://github.com/humanlayer/12-factor-agents/blob/main/content/factor-7-contact-humans-with-tools.md" target="_blank" rel="noopener noreferrer" class="link">Factor 7: Contact humans with tool calls</a></p>
<!-- エラー処理の例 -->
<h2>エラーをコンテキストに集約する例</h2>
<pre><code>consecutive_errors = 0
while True:
// ... existing code ...
try {
result = await handle_next_step(thread, next_step)
thread["events"].append({
"type": next_step.intent + '_result',
data: result,
})
// success! reset the error counter
consecutive_errors = 0
} catch (e) {
consecutive_errors += 1
if (consecutive_errors < 3) {
// do the loop and try again
thread["events"].append({
"type": 'error',
"data": format_error(e),
})
} else {
// break the loop, reset parts of the context window,
// escalate to a human, or whatever else you want to do
break
}
}
}</code></pre>
<p class="source">出典: <a href="https://github.com/humanlayer/12-factor-agents/blob/main/content/factor-9-compact-errors.md" target="_blank" rel="noopener noreferrer" class="link">Factor 9: Compact Errors into Context Window</a></p>
<!-- 小さく焦点を絞ったエージェントの利点 -->
<h2>小さく焦点を絞ったエージェントの利点</h2>
<div class="mermaid">
mindmap
root((小さく焦点を絞った<br>エージェントの利点))
管理しやすいコンテキスト
コンテキストウィンドウが小さい
LLMのパフォーマンス向上
明確な責任
明確に定義された範囲
明確な目的
高い信頼性
複雑なワークフローで迷子になりにくい
容易なテスト
特定機能のテストが簡単
検証が容易
改善されたデバッグ
問題の特定が容易
修正が容易
</div>
<p class="source">出典: <a href="https://github.com/humanlayer/12-factor-agents/blob/main/content/factor-10-small-focused-agents.md" target="_blank" rel="noopener noreferrer" class="link">Factor 10: Small, Focused Agents</a></p>
<!-- コンテキストの事前フェッチ -->
<h2>コンテキストの事前フェッチによる効率化</h2>
<div class="highlight">
<h3>非効率な例:</h3>
<pre><code>// プロンプト
When looking at deployments, you will likely want to fetch the list of published git tags,
so you can use it to deploy to prod.
Here's what happened so far:
{{ thread.events }}
What's the next step?
// コード
thread = {"events": [inital_message]}
next_step = await determine_next_step(thread)
while (true) {
switch (next_step.intent) {
case 'list_git_tags':
tags = await fetch_git_tags()
thread["events"].push({
type: 'list_git_tags',
data: tags,
})
break
// ...
}
}</code></pre>
<h3>効率的な解決策:</h3>
<pre><code>// プロンプト
The current git tags are:
{{ git_tags }}
Here's what happened so far:
{{ thread.events }}
What's the next step?
// コード
thread = {"events": [inital_message]}
git_tags = await fetch_git_tags()
next_step = await determine_next_step(thread, git_tags)
while (true) {
switch (next_step.intent) {
case 'deploy_backend_to_prod':
// 直接デプロイに進む
break
// ...
}
}</code></pre>
</div>
<p class="source">出典: <a href="https://github.com/humanlayer/12-factor-agents/blob/main/content/appendix-13-pre-fetch.md" target="_blank" rel="noopener noreferrer" class="link">Factor 13: Pre-fetch all the context you might need</a></p>
<!-- まとめ -->
<div class="separator"></div>
<h2>12-Factor Agentsの重要性</h2>
<div class="highlight">
<ul>
<li>SaaS企業がAIへの転換を試みる中で、エージェントフレームワークを用いた新規プロジェクトが70-80%の信頼性の壁を超えることが難しい現状がある</li>
<li>既存の製品にエージェント構築のモジュール概念を組み込むことで成功している事例が増えている</li>
<li>これらの原則は、LLMアプリケーションをより信頼性が高く、スケーラブルで、保守しやすいものにするためのエンジニアリングプラクティスを提供する</li>
<li>モデルの性能が向上しても、これらのコア技術は依然として価値を持つ</li>
</ul>
</div>
<p class="source">出典: <a href="https://news.ycombinator.com/item?id=43623589" target="_blank" rel="noopener noreferrer" class="link">12-Factor Agents: Patterns of Great LLM Applications - Hacker News</a></p>
</div>
<script>
document.addEventListener('DOMContentLoaded', function() {
mermaid.initialize({
startOnLoad: true,
theme: 'default',
flowchart: {
useMaxWidth: true,
htmlLabels: true,
curve: 'basis'
},
securityLevel: 'loose'
});
});
</script>
</body>
</html>このレポートが参考になりましたか？
あなたの仕事の調査業務をワンボタンでレポートにできます。
🔍 詳細
🏷12-Factor Agentsの概要と重要性
最新の12-Factor Agents: LLMアプリケーションの信頼性向上法
12-Factor Agentsの概要と重要性
近年、大規模言語モデル（LLM）を活用したアプリケーション開発が活発化していますが、その信頼性をいかに高めるかが重要な課題となっています。「12-Factor Agents」は、LLMを活用したソフトウェアを、より実用的で信頼性の高いものにするための原則をまとめたものです。この原則は、特に本番環境での利用を想定した顧客に提供できるレベルの品質を目指しています。
github.com
従来のソフトウェア開発との比較
「12-Factor Agents」を理解する上で、従来のソフトウェア開発の歴史を振り返ることは有益です。60年前、ソフトウェアは有向グラフ（DG）として表現され、プログラムはフローチャートで視覚化されていました。その後、DAG（有向非巡回グラフ）オーケストレーターが登場し、Airflow、Prefect、Dagsterなどのツールがソフトウェアのモジュール性、可観測性、再試行機能、管理機能を向上させました。これらのツールは、ソフトウェア開発における重要な進歩でしたが、LLMを活用したエージェント開発においては、新たな課題が浮上しています。
github.com
github.com
LLMエージェント開発の課題
LLMエージェントは、従来のDAGとは異なり、目標と遷移のセットに基づいてリアルタイムで意思決定を行います。しかし、コンテキストウィンドウが長くなりすぎると、エージェントは迷子になり、同じアプローチを繰り返すという問題が発生します。これは、LLMエージェントが大規模で複雑なタスクをこなそうとする際に特に顕著になります。
github.com
12-Factor Agentsの原則
「12-Factor Agents」は、このような課題を解決し、LLMエージェントの信頼性を高めるための具体的な指針を提供します。その中でも特に重要なのが、「10. Small, Focused Agents（小さく、焦点を絞ったエージェント）」という原則です。
github.com
この原則では、大きくて複雑なタスクをこなそうとするモノリシックなエージェントを構築するのではなく、特定のことだけをうまくこなす小さく焦点を絞ったエージェントを構築することを推奨しています。小さく焦点を絞ったエージェントには、以下のような利点があります。
github.com
- 管理しやすいコンテキスト: コンテキストウィンドウが小さければ、LLMのパフォーマンスが向上します。github.com
- 明確な責任: 各エージェントは、明確に定義された範囲と目的を持ちます。github.com
- より高い信頼性: 複雑なワークフローで迷子になる可能性が低くなります。github.com
- テストの容易性: 特定の機能をテストおよび検証するのがより簡単になります。github.com
- デバッグの改善: 問題が発生した場合に、問題を特定して修正するのがより簡単になります。github.com
マイクロエージェントの有効性
小さく焦点を絞ったエージェントをさらに発展させた概念として、「マイクロエージェント」というアプローチがあります。これは、エージェントパターンをより広範な決定論的なDAGに組み込むというものです。
github.com
マイクロエージェントの有効性を示す例として、デプロイボットがあります。このデプロイボットは、人間のフィードバックを解析し、更新された行動方針を提案することに特化しています。タスクとコンテキストを可能な限り分離し、LLMが小規模で集中的なワークフローに焦点を当てられるようにします。
github.com
その他の重要な原則
12-Factor Agentsには、他にも以下のような重要な原則があります。
ycombinator.com
- Factor 2: Own your prompts
- Factor 3: Own your context window
- Factor 4: Tools are structured outputs
- Factor 5: Unify execution state
- Factor 7: Contact humans with tool calls
- Factor 8: Own your control flow
- Factor 9: Compact errors into context
- Factor 11: Meet users where they are
- Factor 12: Make your agent a stateless reducer
これらの原則を組み合わせることで、LLMエージェントの信頼性、保守性、拡張性を高めることができます。
結論
「12-Factor Agents」は、LLMを活用したアプリケーション開発において、避けて通れない課題に対する実践的な解決策を提供します。特に、「Small, Focused Agents」の原則は、LLMエージェントの信頼性を高める上で非常に重要です。LLMエージェントを開発する際には、これらの原則を参考に、より高品質で信頼性の高いアプリケーションを目指すべきです。
🏷各要素の詳細解説
最新の12-Factor Agents: LLMアプリケーションの信頼性向上法
各要素の詳細解説
HumanLayerのDex（YC F24）が提唱する「12-Factor Agents」は、大規模言語モデル（LLM）を活用したアプリケーションを本番環境で信頼性高く運用するための原則群です。これらの原則は、AIエージェントの構築経験から得られたものであり、多くのSaaS企業がAIへの転換を試みる中で、エージェントフレームワークを用いた新規プロジェクトが直面する信頼性の課題を解決する糸口となります。Herokuの12-Factor Appsに触発されたこれらの要素は、LLMアプリケーションをよりスケーラブルで保守しやすいものにするためのエンジニアリングプラクティスに焦点を当てています。
ycombinator.com
ycombinator.com
Factor 1: 自然言語からツール呼び出しへ
エージェント構築における一般的なパターンとして、自然言語を構造化されたツール呼び出しに変換することが重要です。例えば、「2月のAIティンカーズミートアップのスポンサーとしてTerriに750ドルの支払いリンクを作成できますか？」という自然言語のフレーズを、Stripe APIの呼び出しを記述する構造化オブジェクトに変換します。
github.com
{
"function": {
"name": "create_payment_link",
"parameters": {
"amount": 750,
"customer": "cust_128934ddasf9",
"product": "prod_8675309",
"price": "prc_09874329fds",
"quantity": 1,
"memo": "Hey Jeff - see below for the payment link for the february ai tinkerers meetup"
}
}
}
実際のAPIはさらに複雑であり、Mailcrewのようなエージェントは、顧客リスト、製品リスト、価格リストなどを参照して適切なIDでペイロードを構築する必要があります。この構造化された出力を基に、決定論的なコードがAPIを呼び出し、処理を実行します。
github.com
この要素が重要なのは、LLMの柔軟性と構造化されたAPIの正確性を組み合わせることで、複雑なタスクを効率的に処理できるからです。
Factor 2: プロンプトを管理する
LLMを活用したソフトウェア開発において、プロンプトの重要性は非常に高いです。プロンプトエンジニアリングをフレームワークに外注するのではなく、プロンプトをコードとして直接管理することを推奨しています。プロンプトを直接管理することで、必要な指示を正確に記述でき、テストと評価、迅速な反復、透明性の確保が可能になります。
github.com
例えば、以下のようなRustのコードでプロンプトを定義できます。
github.com
function DetermineNextStep(thread: string) -> DoneForNow | ListGitTags | DeployBackend | DeployFrontend | RequestMoreInformation {
prompt #"
{{ _.role("system") }}
You are a helpful assistant that manages deployments for frontend and backend systems.
You work diligently to ensure safe and successful deployments by following best practices
and proper deployment procedures.
Before deploying any system, you should check:
- The deployment environment (staging vs production)
- The correct tag/version to deploy
- The current system status
You can use tools like deploy_backend, deploy_frontend, and check_deployment_status
to manage deployments. For sensitive deployments, use request_approval to get
human verification.
Always think about what to do first, like:
- Check current deployment status
- Verify the deployment tag exists
- Request approval if needed
- Deploy to staging before production
- Monitor deployment progress
{{ _.role("user") }}
{{ thread }}
What should the next step be?
"#
}
プロンプトを直接管理することで、開発者はLLMの挙動をより細かく制御し、アプリケーションの要件に合わせて最適化できます。
Factor 3: コンテキストウィンドウを管理する
LLMエージェントへのインプットは「これまでの経緯と次のステップ」であり、最高の出力を得るには最高のインプットが必要です。コンテキストエンジニアリングは、LLMへの入力を最適化する上で重要であり、効果的なコンテキストにはプロンプト、外部データ、過去の状態、関連する履歴からのメッセージ、構造化データの出力指示などが含まれます。多くのLLMクライアントはメッセージベースの標準形式を使用していますが、コンテキストをLLMに伝えるために、よりトークン効率が高く、注意を引くカスタム形式も検討すべきです。
github.com
コンテキストウィンドウを適切に管理することで、情報の密度を高め、エラー処理を改善し、安全性を確保し、柔軟性を持たせ、トークン効率を最適化できます。
github.com
Factor 4: ツールは構造化された出力である
ツールは複雑である必要はなく、LLMからの構造化された出力であり、決定論的なコードをトリガーするものであると述べています。例えば、
github.com
CreateIssueSearchIssuesこのパターンは、LLMの意思決定とアプリケーションのアクションの間に明確な分離を生み出します。LLMは何をすべきかを決定しますが、コードはそれをどのように実行するかを制御します。
github.com
Factor 5: 実行状態とビジネス状態を統合する
AIアプリケーションにおいては、「実行状態」と「ビジネス状態」を統合することで、シンプルさ、シリアライズの容易さ、デバッグの容易さ、柔軟性、復旧の容易さ、分岐の容易さ、人間インターフェースと可観測性の向上といったメリットが得られます。
github.com
- 実行状態: 現在のステップ、次のステップ、待機状態、リトライ回数など、実行に関する情報。
- ビジネス状態: ワークフローでこれまでに発生したこと（OpenAIのメッセージリスト、ツール呼び出しとその結果など）。
可能な限り実行状態とビジネス状態を統合し、コンテキストウィンドウからすべての実行状態を推測できるようにアプリケーションを設計することが推奨されます。
github.com
Factor 6: シンプルなAPIで起動/一時停止/再開
エージェントは単なるプログラムであり、起動、クエリ、再開、停止の方法に期待される要素があります。
github.com
- Launch（起動）: ユーザー、アプリケーション、パイプライン、および他のエージェントが、シンプルなAPIを通じてエージェントを容易に起動できるべきです。
- Pause（一時停止）: 長時間実行される操作が必要な場合、エージェントと、そのオーケストレーションを行う決定論的なコードは、エージェントを一時停止できるべきです。
- Resume（再開）: Webhookのような外部トリガーは、エージェントオーケストレーターとの深い統合なしに、中断した場所からエージェントを再開できるようにするべきです。
Factor 7: ツール呼び出しで人間と連携する
LLM APIが、プレーンテキストと構造化データという根本的な選択に依存している点を指摘しています。LLMが常にJSON形式で出力し、
github.com
request_human_inputdone_for_nowFactor 8: 制御フローを管理する
独自の制御フローを持つことで、特定のユースケースに合わせた様々な機能拡張や制御が可能になります。具体的には、ツールの呼び出し結果の要約やキャッシュ、構造化された出力に対する LLM の判断、コンテキストウィンドウの圧縮、ロギング、レート制限、一時停止などが挙げられます。
github.com
例えば、モデルがより多くの情報を要求した場合、ループを中断し、人間からの応答を待ちます。
github.com
Factor 9: エラーをコンテキストに集約する
エージェントの「自己修復」能力に着目し、短いタスクにおいてLLMがツールを呼び出す際にエラーが発生した場合、エラーメッセージやスタックトレースを解析し、その後のツール呼び出しで修正を試みる点を強調しています。エラーが発生した場合、その情報をコンテキストウィンドウに追加し、再試行することで、エージェントはエラーから学習し、タスクを完了する能力を高めます。
github.com
Factor 10: 小さく、焦点を絞ったエージェント
大規模なエージェントではなく、特定のタスクに特化した小規模で集中的なエージェントを構築することの重要性を強調しています。コンテキストウィンドウを管理しやすくし、LLMのパフォーマンスを高く維持することができます。特定のドメインに焦点を当てたエージェントは、コンテキストウィンドウを管理しやすくし、LLMのパフォーマンスを高く維持することができます。
github.com
Factor 11: ユーザーがいる場所で対応する
この要素は、エージェントが様々なプラットフォームやインターフェースを通じてユーザーと взаимодей взаимодей взаимодей взаимодей взаимодействиеできる柔軟性を重視します。ユーザーがSlack、メール、SMSなどの異なるチャネルを使用している場合でも、エージェントはそれらのチャネルを介してタスクを開始し、情報を交換し、応答を提供できる必要があります。これは、エージェントが特定のプラットフォームに縛られず、ユーザーが最も便利な方法でエージェントと対話できるようにすることを意味します。
github.com
Factor 12: エージェントをステートレスなリデューサーにする
Factor 12は、エージェントをステートレスなリデューサーにすることに焦点を当てています。エージェントをステートレスに保つことで、システムの複雑さを軽減し、予測可能性を高めることを目指します。ステートレスなリデューサーは、関数型プログラミングの概念に基づいており、入力と状態を受け取り、新しい状態を返す純粋な関数として機能します。この原則は、他のFactorエージェントの原則と連携して、LLMを活用したソフトウェアの設計と開発を支援します。
github.com
これらの原則を実践することで、LLMアプリケーションはより信頼性が高く、スケーラブルで、保守しやすいものになります。モデルの性能が向上しても、これらのコア技術は依然として価値を持つと考えられています。
ycombinator.com
🏷エージェント設計のベストプラクティス
以下に、最新の12-Factor Agentsに関するレポートのセクションを記述します。
最新の12-Factor Agents: LLMアプリケーションの信頼性向上法
エージェント設計のベストプラクティス
LLM（大規模言語モデル）を活用したアプリケーション開発において、信頼性と効率性を高めるためのベストプラクティスをまとめたものが「12-Factor Agents」です。これは、従来の12-Factor Appの原則をAIエージェントに応用したもので、特に本番環境での利用を想定した設計指針を提供します。本セクションでは、これらの原則の中から重要な要素をピックアップし、エージェント設計における具体的な考慮事項と実践方法を解説します。
コンテキスト管理の重要性
LLMエージェントにおいて、コンテキスト管理は非常に重要です。LLMエージェントへのインプットは「これまでの経緯と次のステップ」であり、最高の出力を得るためには最高のインプットが必要です。コンテキストエンジニアリングは、LLMへの入力を最適化する上で重要であり、効果的なコンテキストにはプロンプト、外部データ（RAG）、過去の状態、ツール呼び出し、関連する履歴からのメッセージ、構造化データの出力指示などが含まれます。
github.com
github.com
多くのLLMクライアントはメッセージベースの標準形式を使用していますが、コンテキストをLLMに伝えるために、トークン効率が高く、注意を引くカスタム形式も検討すべきです。例えば、以下のようなカスタムコンテキスト形式が考えられます。
github.com
github.com
[
{
"role": "system",
"content": "You are a helpful assistant..."
},
{
"role": "user",
"content": |
Here's everything that happened so far:
<slack_message>
From: @alex
Channel: #deployments
Text: Can you deploy the backend?
</slack_message>
<list_git_tags>
intent: "list_git_tags"
</list_git_tags>
<list_git_tags_result>
tags:
- name: "v1.2.3"
commit: "abc123"
date: "2024-03-15T10:00:00Z"
- name: "v1.2.2"
commit: "def456"
date: "2024-03-14T15:30:00Z"
- name: "v1.2.1"
commit: "ghi789"
date: "2024-03-13T09:15:00Z"
</list_git_tags_result>
what's the next step?
}
]
コンテキストウィンドウを適切に管理することで、情報の密度を高め、エラー処理を改善し、安全性を確保し、柔軟性を向上させ、トークン効率を最適化できます。
github.com
実行状態とビジネス状態の統一
AIアプリケーションにおいては、「実行状態」と「ビジネス状態」を統一することが推奨されます。実行状態とは、現在のステップ、次のステップ、待機状態、リトライ回数など、実行に関する情報です。一方、ビジネス状態とは、ワークフローでこれまでに発生したこと（OpenAIのメッセージリスト、ツール呼び出しとその結果など）を指します。
github.com
これらの状態を統一することで、シンプルさ、シリアライズの容易さ、デバッグの容易さ、柔軟性、復旧の容易性、分岐の容易性、人間インターフェースと可観測性の向上といったメリットが得られます。可能な限り実行状態とビジネス状態を統合し、コンテキストウィンドウからすべての実行状態を推測できるようにアプリケーションを設計することが推奨されます。
github.com
github.com
Launch/Pause/ResumeのAPI設計
エージェントは単なるプログラムであり、起動、クエリ、再開、停止の方法に期待される要素があります。
github.com
- Launch（起動）: ユーザー、アプリケーション、パイプライン、および他のエージェントが、シンプルなAPIを通じてエージェントを容易に起動できるべきです。github.com
- Pause（一時停止）: 長時間実行される操作が必要な場合、エージェントと、そのオーケストレーションを行う決定論的なコードは、エージェントを一時停止できるべきです。github.com
- Resume（再開）: Webhookのような外部トリガーは、エージェントオーケストレーターとの深い統合なしに、中断した場所からエージェントを再開できるようにするべきです。github.com
これらの機能をシンプルなAPIで提供することで、エージェントの柔軟性と再利用性が向上します。
どこからでもトリガー可能にする
ユーザーがSlack、メール、SMSなど、好みのチャネルからエージェントをトリガーできるようにし、エージェントが同じチャネルを介して応答できるようにすることを推奨しています。
github.com
ユーザーが普段利用するチャネルでエージェントとやり取りできるようにすることで、AIアプリケーションをデジタルな同僚のように感じさせることができます。また、イベント、cronジョブ、システム停止といった非人間的なトリガーによってエージェントを起動することも可能です。
github.com
github.com
その他の重要な要素
上記の要素に加えて、以下の要素もエージェント設計において重要です。
- プロンプトの管理: プロンプトを適切に管理し、LLMへの入力を最適化します。github.com
- ツールの構造化された出力: ツールからの出力を構造化し、LLMが理解しやすい形式で提供します。github.com
- コントロールフローの所有: エージェントのコントロールフローを明確に定義し、管理します。github.com
- エラーのコンパクト化: エラー情報をコンパクトにまとめ、コンテキストに含めます。github.com
- 小規模で集中的なエージェント: エージェントを小規模で集中的なタスクに分割し、複雑さを軽減します。github.com
- ステートレスなリデューサー: エージェントをステートレスなリデューサーとして設計し、状態管理を簡素化します。github.com
まとめ
12-Factor Agentsの原則は、LLMアプリケーションの信頼性と効率性を高めるための貴重な指針となります。コンテキスト管理、実行状態とビジネス状態の統一、Launch/Pause/ResumeのAPI設計、どこからでもトリガー可能にすることなど、これらの要素を考慮することで、より堅牢で柔軟なAIエージェントを開発することができます。
🏷実際の事例と成功の要因
最新の12-Factor Agents: LLMアプリケーションの信頼性向上法
実際の事例と成功の要因
大規模言語モデル（LLM）を活用したソフトウェアを本番環境で信頼性高く構築するための原則である「12-Factor Agents」は、LLMアプリケーションをより信頼性が高く、スケーラブルで、保守しやすいものにするためのエンジニアリングプラクティスに焦点を当てています。この原則は、SaaS企業が既存の製品にエージェント構築のモジュール概念を組み込むことでAIへの転換を試みる際に、特に重要な成功要因となり得ます。
ycombinator.com
ycombinator.com
ycombinator.com
SaaS企業のAI転換とエージェントフレームワーク
SaaS企業がAIへの転換を試みる際、既存の製品にエージェント構築のモジュール概念を組み込むことで成功している事例が見られます。これは、AI技術を既存のビジネスモデルに統合し、新たな価値を創造する効果的なアプローチと言えるでしょう。しかし、エージェントフレームワークを用いた新規プロジェクトが70-80%の信頼性の壁を超えることが難しい現状を打破する必要があることも指摘されています。
ycombinator.com
ycombinator.com
12-Factor Agentsの各要素と成功要因
12-Factor Agentsは、LLMエージェントを構築するための12の要素から構成されており、それぞれがLLMアプリケーションの信頼性、スケーラビリティ、保守性を向上させるための具体的なプラクティスを提示しています。
- 自然言語からツール呼び出しへ (Factor 1): 自然言語を構造化されたツール呼び出しに変換することは、LLMエージェントが外部ツールと連携し、タスクを実行するために不可欠です。例えば、「2月のAIティンカーズミートアップのスポンサーとしてTerriに750ドルの支払いリンクを作成できますか？」という自然言語のフレーズを、Stripe API呼び出しを記述する構造化オブジェクトに変換することで、LLMエージェントが自動的に支払いリンクを作成できますycombinator.com。github.com
{ "function": { "name": "create_payment_link", "parameters": { "amount": 750, "customer": "cust_128934ddasf9", "product": "prod_8675309", "price": "prc_09874329fds", "quantity": 1, "memo": "Hey Jeff - see below for the payment link for the february ai tinkerers meetup" } } } - プロンプトを管理する (Factor 2): フレームワークに依存せず、プロンプトを直接管理することで、柔軟な開発を可能にします。プロンプトはLLMエージェントの挙動を制御するための重要な要素であり、プロンプトを適切に管理することで、LLMエージェントのパフォーマンスを最適化できますycombinator.com。github.com
- コンテキストウィンドウを管理する (Factor 3): LLMエージェントへの最適なインプットを提供するために、コンテキストエンジニアリングを行い、情報の密度、エラー処理、安全性、柔軟性、トークン効率を高めることは、LLMエージェントのパフォーマンスを向上させるために重要です。コンテキストウィンドウを適切に管理することで、LLMエージェントがより正確な判断を下し、タスクを完了する能力を高めることができますycombinator.com。github.com
- ツールは構造化された出力である (Factor 4): ツールをLLMからの構造化された出力として捉え、決定論的なコードをトリガーすることは、LLMエージェントの挙動を予測可能にし、信頼性を高めるために重要です。ツール呼び出しを構造化された出力として扱うことで、LLMエージェントがより効率的にタスクを実行し、エラーを減らすことができますycombinator.com。github.com
- 実行状態とビジネス状態を統合する (Factor 5): AIアプリケーションにおいて、実行状態とビジネス状態を統一することで、シンプルさ、シリアライズの容易さ、デバッグの容易さ、柔軟性、復旧の容易さ、分岐の容易さ、人間インターフェースと可観測性を向上させることは、AIアプリケーションの開発と運用を効率化するために重要です。実行状態とビジネス状態を統合することで、AIアプリケーションの状態をより正確に把握し、問題を解決しやすくなりますycombinator.com。github.com
- シンプルなAPIで起動/一時停止/再開 (Factor 6): エージェントのライフサイクル管理を容易にし、長時間実行される操作に対応するために、シンプルなAPIを通じてエージェントを起動、一時停止、再開できるようにすることは、LLMエージェントの運用を効率化するために重要です。シンプルなAPIを通じてエージェントを管理することで、LLMエージェントの利用状況を監視し、必要に応じてリソースを調整することができますycombinator.com。github.com
- ツール呼び出しで人間と連携する (Factor 7): LLMがJSON形式で出力し、自然言語トークンで意図を宣言することで、人間との連携を可能にすることは、LLMエージェントが人間と協力してタスクを実行するために重要です。人間との連携を可能にすることで、LLMエージェントがより複雑なタスクを実行し、人間の知識や経験を活用することができますycombinator.com。github.com
- 制御フローを管理する (Factor 8): 独自の制御フローを持つことで、特定のユースケースに合わせた機能拡張や制御を可能にすることは、LLMエージェントの柔軟性を高めるために重要です。独自の制御フローを持つことで、LLMエージェントが特定のタスクに特化した挙動を実現し、パフォーマンスを最適化することができますycombinator.com。github.com
- エラーをコンテキストに集約する (Factor 9): エラー情報をコンテキストウィンドウに追加し、再試行することで、エージェントがエラーから学習し、タスクを完了する能力を高めることは、LLMエージェントの信頼性を高めるために重要です。エラー情報をコンテキストに集約することで、LLMエージェントが過去のエラーから学習し、同じエラーを繰り返さないようにすることができますycombinator.com。github.com
- 小さく、焦点を絞ったエージェント (Factor 10): 特定のタスクに特化した小規模で集中的なエージェントを構築することで、コンテキストウィンドウを管理しやすくし、LLMのパフォーマンスを高く維持することは、LLMエージェントの効率を高めるために重要です。小規模で集中的なエージェントを構築することで、LLMエージェントのコンテキストウィンドウを管理しやすくし、LLMのパフォーマンスを高く維持することができますycombinator.com。github.com
- ユーザーがいる場所で対応する (Factor 11): ユーザーが普段利用するチャネル（Slack、メール、SMSなど）からエージェントをトリガーできるようにし、同じチャネルを介して応答できるようにすることで、AIアプリケーションをデジタルな同僚のように感じさせることは、LLMエージェントのユーザビリティを高めるために重要です。ユーザーが普段利用するチャネルからエージェントをトリガーできるようにすることで、LLMエージェントをより身近な存在にし、利用頻度を高めることができますycombinator.com。github.com
- エージェントをステートレスなリデューサーにする (Factor 12): エージェントをステートレスに保つことで、システムの複雑さを軽減し、予測可能性を高めることは、LLMエージェントの保守性を高めるために重要です。エージェントをステートレスに保つことで、LLMエージェントの挙動を予測可能にし、デバッグやテストを容易にすることができますycombinator.com。github.com
マイクロエージェントとコンテキストの事前フェッチ
エージェントパターンをより広範な決定論的なDAGに組み込むアプローチであるマイクロエージェントは、コンテキストウィンドウが長くなるほど、小規模で焦点を絞ったプロンプトとコンテキストを使用する方が良い結果が得られるため有効です。また、モデルがツールを呼び出す可能性が高い場合、そのツールを事前にフェッチしてコンテキストウィンドウに含めることで、効率を高めることができます。
github.com
github.com
GitHub Copilotの事例
GitHub Copilotは、AI搭載の開発者向けプラットフォームであり、GitHub Copilotがワークフロー全体に組み込まれており、迅速かつ安全にコードを構築できます。AI搭載のコーディング支援により、生産性が向上し、コード補完、チャットなどが利用できます。55%の高速化が可能です。これは、AI技術を開発プロセスに統合し、開発者の生産性を向上させる成功事例と言えるでしょう。
github.com
github.com
まとめ
12-Factor Agentsは、LLMアプリケーションを本番環境で信頼性高く構築するための原則であり、SaaS企業がAIへの転換を試みる際に、既存の製品にエージェント構築のモジュール概念を組み込むことで成功している事例に見られるように、重要な成功要因となり得ます。12-Factor Agentsの各要素を理解し、適切に適用することで、LLMアプリケーションの信頼性、スケーラビリティ、保守性を向上させることができます。
調査のまとめ
回答
「12-Factor Agents」は、大規模言語モデル（LLM）を活用したソフトウェアを本番環境で信頼性高く構築するための原則です。[1](https://news.ycombin...
🏷今後の展望と課題
最新の12-Factor Agents: LLMアプリケーションの信頼性向上法
今後の展望と課題
LLM（大規模言語モデル）を活用したアプリケーション開発において、信頼性を高めるための原則をまとめた「12-Factor Agents」は、今後のAIシステム開発において重要な指針となると考えられます。特に、小さく焦点を絞ったエージェントの設計や、コンテキストの事前取得といった要素は、LLMの能力を最大限に引き出し、効率的なシステム構築を実現するために不可欠です。
ycombinator.com
小さく焦点を絞ったエージェントの重要性
12-Factor Agentsの原則の一つである「Small, Focused Agents（小さく、焦点を絞ったエージェント）」は、LLMを活用したソフトウェア開発において、複雑なタスクをこなそうとするモノリシックなエージェントを構築するのではなく、特定のことだけをうまくこなす小さく焦点を絞ったエージェントを構築することを推奨しています。
github.com
このアプローチには、以下のような利点があります。
github.com
- 管理しやすいコンテキスト: コンテキストウィンドウが小さければ、LLMのパフォーマンスが向上します。
- 明確な責任: 各エージェントは、明確に定義された範囲と目的を持ちます。
- より高い信頼性: 複雑なワークフローで迷子になる可能性が低くなります。
- テストの容易性: 特定の機能をテストおよび検証するのがより簡単になります。
- デバッグの改善: 問題が発生した場合に、問題を特定して修正するのがより簡単になります。
たとえLLMが進化してより多くのステップを処理できるようになったとしても、エージェントのスコープを小さく保ち、品質を維持しながら徐々に拡張していくことが重要です。NotebookLMのチームが述べたように、AI構築における最も魔法のような瞬間は、モデルの能力の限界に近いときに生まれるという考えを紹介しています。
github.com
github.com
コンテキストの事前取得による効率化
AIエンジニアリングにおいて、コンテキストエンジニアリングは非常に重要です。モデルがツールを呼び出す可能性が高い場合、モデルにツールをフェッチするように指示するトークンラウンドトリップを浪費しないことが推奨されています。
github.com
github.com
例えば、デプロイメントを検討する際に、公開されているgitタグのリストをフェッチする必要がある場合、非効率な方法では、まず。
list_git_tagsgithub.com
When looking at deployments, you will likely want to fetch the list of published git tags,
so you can use it to deploy to prod.
Here's what happened so far:
{{ thread.events }}
What's the next step?
Answer in JSON format with one of the following intents:
{
intent: 'deploy_backend_to_prod',
tag: string
} OR {
intent: 'list_git_tags'
} OR {
intent: 'done_for_now',
message: string
}
より効率的な解決策は、タグを事前にフェッチしてコンテキストウィンドウに含めることです。
github.com
- When looking at deployments, you will likely want to fetch the list of published git tags,
- so you can use it to deploy to prod.
+ The current git tags are:
+ {{ git_tags }}
Here's what happened so far:
{{ thread.events }}
What's the next step?
Answer in JSON format with one of the following intents:
{
intent: 'deploy_backend_to_prod',
tag: string
- } OR {
- intent: 'list_git_tags'
} OR {
intent: 'done_for_now',
message: string
}
これにより、モデルはタグをフェッチするための追加のステップを省き、より迅速にデプロイメントの意思決定を行うことができます。
その他の重要な要素
12-Factor Agentsには、他にも以下のような重要な要素が含まれています。
ycombinator.com
- Factor 2: Own your prompts
- Factor 3: Own your context window
- Factor 4: Tools are structured outputs
- Factor 5: Unify execution state
- Factor 7: Contact humans with tool calls
- Factor 8: Own your control flow
- Factor 9: Compact errors into context
- Factor 11: Meet users where they are
- Factor 12: Make your agent a stateless reducer
これらの要素を組み合わせることで、LLMアプリケーションの信頼性、効率性、保守性を向上させることができます。
今後の課題
12-Factor Agentsは、LLMアプリケーション開発における重要な原則を提供しますが、今後の課題も存在します。
- 原則の進化: AI技術は急速に進化しており、12-Factor Agentsの原則も、技術の進歩に合わせて進化していく必要があります。
- 具体的な実装: 12-Factor Agentsの原則を具体的なコードに落とし込むためのベストプラクティスを確立する必要があります。
- コミュニティの形成: 12-Factor Agentsの原則を共有し、議論するためのコミュニティを形成する必要があります。
これらの課題に取り組むことで、12-Factor Agentsは、LLMアプリケーション開発の標準となり、より信頼性の高いAIシステムの構築に貢献すると考えられます。
🖍 考察
調査の本質
今回の調査依頼は、LLM（大規模言語モデル）を活用したエージェントの信頼性と運用効率を向上させるための設計指針「12-Factor Agents」に着目したものです。表面的には、自然言語から構造化されたツール呼び出しへの変換、プロンプトやコンテキストの厳密な管理、小規模で焦点を絞ったエージェント設計など、多岐にわたる実装技術・運用方法が示されています。しかし、その背後にある真のニーズは、急速に進化するAI技術を実運用環境で安定・効率的に活用するために、システム全体の複雑性を抑え、一貫した信頼性と保守性を確保するエンジニアリングプラクティスの確立にあります。
分析と発見事項
調査結果からは、以下の重要なポイントが明確に浮かび上がります。
-
自然言語からのツール呼び出し
- ユーザーが日常的に使う自然言語を、具体的なAPIコール（例：Stripe APIによる支払いリンク生成）へと変換する仕組みが紹介されています。これにより、LLMが柔軟かつ正確なアウトプットを生成できる点が評価されます。github.com
- ユーザーが日常的に使う自然言語を、具体的なAPIコール（例：Stripe APIによる支払いリンク生成）へと変換する仕組みが紹介されています。これにより、LLMが柔軟かつ正確なアウトプットを生成できる点が評価されます。
-
プロンプトとコンテキストの管理
- プロンプトの直接管理と、コンテキストウィンドウの最適化が、LLMのパフォーマンス向上に不可欠であることが示されています。特に、LLMの混乱を避けるために、実行状態とビジネス状態の統合管理が強調されています。github.com
- プロンプトの直接管理と、コンテキストウィンドウの最適化が、LLMのパフォーマンス向上に不可欠であることが示されています。特に、LLMの混乱を避けるために、実行状態とビジネス状態の統合管理が強調されています。
-
小規模で焦点を絞ったエージェント設計
- モノリシックなエージェントではなく、特定のタスクに特化した小規模なエージェントを構築することで、コンテキスト管理の負荷を軽減し、テストやデバッグ、運用の容易性が向上する点が確認されました。github.com
- モノリシックなエージェントではなく、特定のタスクに特化した小規模なエージェントを構築することで、コンテキスト管理の負荷を軽減し、テストやデバッグ、運用の容易性が向上する点が確認されました。
-
実行・停止・再開のAPI設計
- エージェントのライフサイクル管理（起動、停止、再開）をシンプルなAPIで実現することが、運用時の柔軟性や信頼性向上に寄与しているといった実例も示されています。github.com
- エージェントのライフサイクル管理（起動、停止、再開）をシンプルなAPIで実現することが、運用時の柔軟性や信頼性向上に寄与しているといった実例も示されています。
より深い分析と解釈
調査結果をさらに深堀りするために、以下の「なぜ？」を3段階で考察します。
-
なぜ小規模で焦点を絞ったエージェントが必要なのか？
- 【第一段階】：大規模なモノリシックなエージェントは、タスクが複雑になるにつれてコンテキストが肥大化し、LLMが誤った判断を下す可能性が高まります。
- 【第二段階】：コンテキストが適切に管理されれば、エージェントは明確な責務に基づいて動作し、エラーやデバッグの際に問題箇所の特定が容易になります。
- 【第三段階】：結果として、システム全体の運用安定性や保守性が向上し、実環境での信頼性が確保されるというメリットが生まれます。
-
なぜプロンプトとコンテキストの管理が重視されるのか？
- 【第一段階】：LLMはこれまでの文脈や入力データに大きく依存してアウトプットを生成するため、適切な入力管理が不可欠です。
- 【第二段階】：不適切なコンテキストは誤った判断や繰り返しの無駄な処理を誘発し、システム全体の効率低下につながります。
- 【第三段階】：徹底したプロンプト管理とコンテキストの最適化は、LLMのパフォーマンス向上および予測可能な動作を実現し、実運用上のリスクを大幅に低減します。
-
なぜ統一されたAPI設計が戦略上重要なのか？
- 【第一段階】：一貫したAPI設計により、異なるエージェントやサービス間の連携がスムーズに行われ、全体としてのシステム統合性が向上します。
- 【第二段階】：起動、停止、再開などのライフサイクル管理が一元化されることで、エラーの早期検知や対応が容易になり、運用リスクが低減します。
- 【第三段階】：この統一性がシステムのスケーラビリティと柔軟性につながり、長期的な運用の信頼性確保に寄与します。
戦略的示唆
上記の分析を踏まえ、以下の実践的なアクションを提案します。
-
モジュール化されたエージェント設計の導入
- 各エージェントの責任範囲を明確にし、小規模で集中的なタスク処理を行うことで、全体の複雑性を低減する設計手法を採用する。
-
プロンプト・コンテキスト管理の徹底
- LLMへ提供する入力データの整理と、実行状態およびビジネス状態の統合管理をシステム設計の初期段階から導入し、定期的な評価とチューニングを実施する。
-
統一APIの活用によるライフサイクル管理
- エージェントの起動、停止、再開に関する一元管理可能なAPIを開発し、運用時の柔軟なリソース調整や障害対応を迅速化する。
-
エラーハンドリングと自己修復メカニズムの拡充
- エラー情報をコンテキストに集約し、自動的に再試行や修正を試みる仕組みを実装することで、システム全体の堅牢性を向上させる。
これらの示唆は、既存のLLMアプリケーションをより信頼性の高い運用環境へとシフトさせるための具体的な方向性を示しています。
今後の調査の提案
今回の考察を踏まえ、以下の追加調査テーマを検討することが望まれます。
-
異なるスケールでの12-Factor Agentsの適用検証
- 小規模プロジェクトと大規模システムで、各原則の効果や運用上の違いを実験的に評価する。
-
コンテキスト最適化手法の詳細評価
- LLMの出力品質向上に向けた、プロンプト・コンテキスト管理の最適化アルゴリズムの検討と、その実装効果の定量評価。
-
自己修復機能とエラーハンドリングの高度化
- エラー情報のコンパクト化と再試行ロジック、そしてエージェント間の連携による自己修復メカニズムの実装と、その実運用効果の分析。
-
複数エージェント間の連携プロトコルの策定
- 異なるエージェントが円滑に連携するための通信プロトコルや、状態統合の標準化に関する研究および実装ガイドラインの構築。
これらの調査を進めることで、12-Factor Agentsの原則をさらに深化させ、実運用における信頼性、効率性、保守性の向上に寄与することが期待されます。
このレポートが参考になりましたか？
あなたの仕事の調査業務をワンボタンでレポートにできます。
📖 レポートに利用された参考文献
検索結果: 0件追加のソース: 17件チャット: 1件
17件の参考文献から18件の情報を精査し、約90,000語の情報を整理しました。あなたは約8時間の調査時間を削減したことになります🎉
調査された文献
17件
精査された情報
18件
整理された情報量
約90,000語
削減された時間
約8時間
🏷 12-Factor Agentsの概要と重要性
How We Got Here: A Brief History of Software
<!DOCTYPE html>
<p><html
lang="en"
data-color-mode="auto" data-light-theme="light" data-dark-th...
continue to get exponentially more powerful
<!DOCTYPE html>
<p><html
lang="en"
data-color-mode="auto" data-light-theme="light" data-dark-th...
🏷 各要素の詳細解説
Factor 12: Make your agent a stateless reducer
<!DOCTYPE html>
<p><html
lang="en"
data-color-mode="auto" data-light-theme="light" data-dark-th...
12-Factor Agents: Patterns of Great LLM Applications
|
| |||||||||||||
26 points by |
Howdy HN - I'm Dex from HumanLayer (YC F24), and I've been buildin...
Factor 10: Small, Focused Agents
<!DOCTYPE html>
<p><html
lang="en"
data-color-mode="auto" data-light-theme="light" data-dark-th...
Factor 9: Compact Errors into Context Window
<!DOCTYPE html>
<p><html
lang="en"
data-color-mode="auto" data-light-theme="light" data-dark-th...
Factor 8: Own your control flow
<!DOCTYPE html>
<p><html
lang="en"
data-color-mode="auto" data-light-theme="light" data-dark-th...
Factor 7: Contact humans with tool calls
<!DOCTYPE html>
<p><html
lang="en"
data-color-mode="auto" data-light-theme="light" data-dark-th...
Factor 6: Launch/Pause/Resume with simple APIs
<!DOCTYPE html>
<p><html
lang="en"
data-color-mode="auto" data-light-theme="light" data-dark-th...
Factor 5: Unify execution state and business state
<!DOCTYPE html>
<p><html
lang="en"
data-color-mode="auto" data-light-theme="light" data-dark-th...
Factor 4: Tools are just structured outputs
<!DOCTYPE html>
<p><html
lang="en"
data-color-mode="auto" data-light-theme="light" data-dark-th...
Factor 3: Own your context window
<!DOCTYPE html>
<p><html
lang="en"
data-color-mode="auto" data-light-theme="light" data-dark-th...
Factor 2: Own your prompts
<!DOCTYPE html>
<p><html
lang="en"
data-color-mode="auto" data-light-theme="light" data-dark-th...
Factor 1: Natural Language to Tool Calls
<!DOCTYPE html>
<p><html
lang="en"
data-color-mode="auto" data-light-theme="light" data-dark-th...
🏷 エージェント設計のベストプラクティス
Factor 11: Trigger from anywhere, meet users where they are
<!DOCTYPE html>
<p><html
lang="en"
data-color-mode="auto" data-light-theme="light" data-dark-th...
Factor 6: Launch/Pause/Resume with simple APIs
<!DOCTYPE html>
<p><html
lang="en"
data-color-mode="auto" data-light-theme="light" data-dark-th...
Factor 5: Unify execution state and business state
<!DOCTYPE html>
<p><html
lang="en"
data-color-mode="auto" data-light-theme="light" data-dark-th...
Factor 3: Own your context window
<!DOCTYPE html>
<p><html
lang="en"
data-color-mode="auto" data-light-theme="light" data-dark-th...
🏷 実際の事例と成功の要因
GitHub · Build and ship software on a single, collaborative platform
# Build and ship software on a single, collaborative platform
Join the world’s most widely adopted ...
調査のまとめ
#### 回答
「12-Factor Agents」は、大規模言語モデル（LLM）を活用したソフトウェアを本番環境で信頼性高く構築するための原則です。[1](https://news.ycombin...
🏷 今後の展望と課題
continue to get exponentially more powerful
<!DOCTYPE html>
<p><html
lang="en"
data-color-mode="auto" data-light-theme="light" data-dark-th...
Factor 13: Pre-fetch all the context you might need
<!DOCTYPE html>
<p><html
lang="en"
data-color-mode="auto" data-light-theme="light" data-dark-th...
📖 レポートに利用されていない参考文献
検索結果: 0件追加のソース: 0件チャット: 0件
📊 ドメイン統計
参照ドメイン数: 2引用済み: 2総文献数: 17
1
引用: 16件/ 総数: 16件
引用率: 100.0%
2
引用: 1件/ 総数: 1件
引用率: 100.0%
このレポートが参考になりましたか？
あなたの仕事の調査業務をワンボタンでレポートにできます。