はじめに
本記事は、Microsoft Agent Framework（MAF）と C#（.NET）を用いて AI エージェントを本番運用するための「Context Engineering 完全ガイド」シリーズの全 8 回中の第 1 回です。
生成AI エージェントのプロトタイプ（PoC）を作ることは比較的容易ですが、それを本番環境で安定的に動かすには、コンテキスト管理に関するさまざまな設計上の工夫が必要です。本シリーズでは、業界で確立したベストプラクティスを「7 つの設計観点」で整理し、実装まで含めて体系的に解説します。業務系エージェント開発に携わるエンジニアの方々のご参考になれば幸いです。
本シリーズの 7 つの設計観点は、実装フェーズ の設計指針を扱います。実装に入る前の 計画フェーズ(「エージェントの成果は何か」「必要な情報は何か」「情報をどう収集するか」)については、Microsoft ai-agents-for-beginners の「Planning Strategies」もあわせてご参照ください。本シリーズは、計画フェーズが完了した後の実装ガイドとして位置付けています。
次回：第 2 回 ツール設計
🗺️ 単独でも読めます:本記事(第1回)にて、Context Engineeringに必要な7つの設計観点の全体像が理解できます。
興味のある観点だけ、第2回以降を個別にお読みください。
📝 本シリーズの制作について
本シリーズは、生成 AI で作成した草案をベースに、筆者が実装検証・加筆・修正を重ねて執筆しています。技術的な内容(API 仕様、論文、ベンチマーク等)は Web 上の一次情報で確認していますが、AI エージェント領域は変化が速いため、誤りや古い情報が含まれる可能性があります。お気づきの点はコメントでご指摘ください。
📝 本記事の要点
- 問題: AI エージェントを PoC から本番運用に上げる際、必ず「コンテキスト爆発・コスト爆発・ドリフト・説明責任」の 4 つの壁にぶつかる
- 解決: Context Engineering を 7 つの設計観点 に分解し、観点漏れなく実装することで本番運用が成立する
- 本書の特徴: 2026年6月時点で、Microsoft Agent Framework (MAF) + C# (.NET) を軸に主要な観点を一通りカバーしたガイドです。
時間がない方は §2「7 つの設計観点」 と §9「本書の読み方」 だけでも、シリーズ全体の地図が手に入ります。
🎯 本記事の対象者
- AI エージェントを 本番運用 したい（PoC 止まりにしたくない）
- Microsoft Agent Framework / Semantic Kernel で実装している
- 「コーディング支援」だけでなく 業務系エージェントの実装 を検討している
- 特定ベンダーに縛られず、2026 年 6 月末時点での ベストプラクティスを知りたい
1. なぜ Context Engineering が重要か
本記事を執筆したきっかけですが、Prompt Engineering については OpenAI 社や Anthropic 社が LLM 利用のガイドを公開しており、開発現場でも一般的な知識となっています。一方で Agent Skills や AGENTS.md を活用した 長時間実行可能なエージェント を開発しようとすると、Prompt Engineering だけでは対処できない課題に直面し、Context Engineering を正しく理解・整理する必要があると感じました。
具体的には、エージェントを本番運用に移行する際に、以下 4 つの壁 にぶつかります。
- コンテキスト爆発:会話やツール履歴がコンテキストウィンドウを圧迫する
- トークン浪費・コスト増大:ツール呼び出し結果を無制限に流し込むと発生する
- ドリフト(脱線):多段タスクで最初に立てた計画をエージェントが途中で忘れる
- 説明責任の欠如:監査要件がある場合、何を根拠に判断したかを追跡できない
これらの壁は Prompt Engineering だけでは解決できず、コンテキストそのものを設計・運用する 技術が必要になります。それが「Context Engineering」と呼ばれる領域です。
2. 📐 パターン：7 つの設計観点で考える
本記事では Context Engineering を 7 つの設計観点 (Design Perspectives) に整理しました。各観点は互いに独立しており、Context という共通の対象を異なる角度から設計するための指針となっています。本番運用に耐えるエージェントは、この 7 観点すべてを網羅すること（観点漏れがないこと） で初めて成立します。
7 つの設計観点
各観点は独立した課題を扱っており、番号は推奨する検討順序を示しています。前の観点が固まるほど後の観点の効果が高まります。また、どれか1つでも欠けると本番運用時にエージェントを長時間実行する際に破綻する可能性が高くなります。
| # | テーマ | 解決する課題 | 記事 |
|---|---|---|---|
| 1 | 入力の質を制御する | ツール出力がコンテキストを汚染する | 第 2 回 |
| 2 | 入力の量を制御する | MCP 結果が巨大になりコストが爆発する | 第 3 回 |
| 3 | 時間を分割する（履歴圧縮） | 長時間セッションで履歴が肥大化する | 第 4 回 |
| 4 | 空間を分割する （サブエージェント） |
複雑なタスクがメイン Context を汚す | 第 5 回 |
| 5 | 記憶を持つ（Memory） | セッション終了で学習内容が消える | 第 6 回 |
| 6 | 進捗を追跡する （TODO / Recitation） |
多段タスクで計画をエージェントが忘れる | 第 7 回 |
| 7 | 能力・指示を宣言する （Skills/AGENTS.md） |
規約・能力定義がコードに散在する | 第 8 回 |
3. 📚 業界の共通語彙との対応
上記の設計観点と、LangChainやAnthropicなどが公開している内容との対応は以下の通りとなっています。他の業界資料を読む際の参照としてご活用ください。
LangChain の Write/Select/Compress/Isolate との対応
| 業界共通語彙 | 内容 | 本書の対応する設計観点 |
|---|---|---|
| Select | 必要な情報を取り出す（検索・選別） | 設計観点 1, 7 |
| Compress | 情報を圧縮する（要約・トリミング） | 設計観点 2, 3 |
| Write | コンテキストに情報を書き込む（保存・記憶） | 設計観点 5, 6, 7 |
| Isolate | コンテキストを分離する（サブエージェント） | 設計観点 4 |
Anthropic 公式 4 戦略との対応
Anthropic Engineering「Effective context engineering for AI agents」(2025/9/29)で公式に整理された 4 戦略との対応は以下の通りです。
| Anthropic 4 戦略 | 公式定義 | 本書の対応する設計観点 |
|---|---|---|
| Curating tools | LLM が呼べるツールセットを精査・絞り込む | 設計観点 1 |
| Tool result truncation / Compaction edits | ツール出力と履歴を構造化的に削減する | 設計観点 2, 3 |
| Multi-agent architectures | サブエージェントによる context 分離 | 設計観点 4 |
| Memory / Plan tracking / Skill packaging | 状態と能力を宣言的に管理する | 設計観点 5, 6, 7 |
LangChain の Write/Select/Compress/Isolate は技術的な操作軸、Anthropic 4 戦略は 設計責務軸 での整理となっています。本記事はこれらを7つの設計観点で整理した「業務系向けの実装ガイド」となることを目的としています。
Manus の 3 戦略との対応
また、Manus 社(汎用 AI エージェント企業、2025 年に Meta が買収)が LangChain と共同で整理した 3 戦略は以下の通りとなっています。
| Manus の 3 戦略 | 内容 | 本書の対応する設計観点 |
|---|---|---|
| Reduce Context | tool result を full と compact の 2 段階で表現 |
設計観点 2, 3 |
| Offload Context | ファイルシステム等の外部ストレージへ退避 | 設計観点 5 |
| Isolate Context | サブエージェントによる分離 | 設計観点 4 |
それぞれの企業で呼び方が異なっても、解決したい課題・目的は同じものになっています。
4. 🧠 業界の最新研究：知っておくべき 3 概念
4-1. Lost-in-the-Middle と Context Rot
Liu et al. (2023) の論文「Lost in the Middle」は、LLM がコンテキストの 先頭と末尾は読めるが中間は読み飛ばす 傾向を実証しました。
この問題について最新モデルではかなり改善されてきています(下表)。どのモデルを利用するか検討する際にはベンチマーク指標の一つである「MRCR v2」スコアをご確認ください。
※ MRCR v2 は long-context 対応力を測る needle-in-haystack 型のベンチマークです。詳細は §用語集を参照。
| モデル系 | リリース時期 | MRCR v2 ベンチマーク | 劣化パターン |
|---|---|---|---|
| Claude Sonnet 4.5 | 〜 2025/12 | 18.5% | 緩やかな U 字 |
| Claude Opus 4.6 | 2026/2 | 76% | 大幅改善するも完全解決ではない |
| GPT-5.4 以前 | 〜 2026 初頭 | 36.6% | cliff-edge（急激な劣化） |
| GPT-5.5 | 2026/4 | 74% | cliff-edge は残るが閾値が上昇 |
| Gemini 3.1 Pro | 2026 | 高水準 | 波状の劣化パターン |
一方で Chroma Research の 「Context Rot」研究(2025/7)は、当時の 18 の主要モデル全てで長文脈による性能劣化 を実証しました。ただし 2026 年に登場した Claude Opus 4.6 や GPT-5.5 では大幅に改善しており(上表)、Lost-in-the-Middle 問題は完全解決には至らないものの、緩和傾向にあります。
またモデルファミリーごとに下記のような「失敗の癖」があることが知られており、「モデル選択だけでは Context Engineering の必要性は消えない」ことを意味します。
| モデル系 | 特徴的な失敗パターン |
|---|---|
| Claude 系 | 劣化は最も緩やか、しかし 「安全のため」と称してタスクを途中放棄する傾向あり |
| GPT 系 | ある閾値を超えると cliff-edge（崖落ち） で急激に劣化 |
| Gemini 系 | 独自の 波状の劣化パターン |
実装時の考慮事項
- ✗ 「Claude Opus 4.8 を使えば Lost-in-the-Middle は解決」と思わない
- ✗ 「1M context window だから何でも入れられる」と思わない
- ✓ 「何を入れるか・何を入れないか」の設計が依然として本質
- ✓ モデル選択時は、自分のタスクで最も起きそうな失敗パターンと相性を見る
4-2. Context Window ≠ Working Memory
Anthropic 公式は LLM のコンテキストを "Working Memory" と表現していますが、ツールなどを用い一時的に作業情報を記録することもあるため、本記事ではContext WindowとWorking Memoryとを区別して扱います。
またもう少し分かりやすく言い換えると、下記のように表現できます。
- 机の広さ（=ウィンドウサイズ）：物理的な上限
- 机の整理（=Context Engineering）：実用上の能力
机が広くても散らかっていたら作業はできません。Context Windowが 1M と拡大しても机の整理（=Context Engineering）は必要です。
4-3. Context の 4 つの失敗モード
Drew Breunig が 2025 年に整理し、Manus 社の論文でも採用された業界共通の語彙です。
| 失敗モード | 内容 | 主な対策 |
|---|---|---|
| ① Context Poisoning | ハルシネーションが context に入り、それが反復される | ツール結果の検証、再生成、設計観点 2 の境界管理 |
| ② Context Distraction | 大量の context が学習挙動を上書きする | Compaction（設計観点 3）、Recitation（設計観点 6） |
| ③ Context Confusion | 不要・無関係な情報が応答に影響する | Select の精密化、結果のトリミング |
| ④ Context Clash | context の各部分が矛盾する | 整合性検証、矛盾検出ロジック |
本書の 7 つの設計観点は、これらの失敗モードを防ぐための実装パターンとして位置付けられます。
5. 🌐 業界研究・動向(参考)
📚 クリックで展開:Context Engineering の業界動向(2023〜2026)整理
主要な業界研究・実装を時系列で整理します。本シリーズを読み進める際の背景知識としてお役立てください。
| 時期 | 出来事 | 影響 |
|---|---|---|
| 2023/7 | Liu et al. 「Lost in the Middle」論文 | Lost-in-the-Middle 問題 の理論的基盤 |
| 2025/7 | Manus 社「Context Engineering for AI Agents: Lessons from Building Manus」(Part 1) | 6 原則 が業界標準化 |
| 2025/7 | Chroma Research「Context Rot」 | 18 モデル全てで性能劣化を実証 |
| 2025/9 | Anthropic 公式「Effective context engineering for AI agents」 | 用語の 公式定義 |
| 2025/10 | Manus + LangChain(Lance Martin)共同ウェビナー | 3 戦略への整理(Reduce / Offload / Isolate) |
| 2025/12 | Philipp Schmid「Context Engineering for AI Agents: Part 2」 | Context Rot、Compaction vs Summarization、Agent Harness |
| 2026/2 | Claude Opus 4.6 リリース(MRCR v2 で 76%) | 長文脈性能が 309% 改善 (Sonnet 4.5比) |
| 2026/4 | GPT-5.5 リリース(MRCR v2 で 74%) | GPT-5.4 比で 約 2 倍改善 |
| 2026/5 | arXiv「Classifier Context Rot」 | 安全モニター失敗率 2〜30 倍 を実証 |
| 2026/6 | arXiv「Plan Persistence in LLM Agents」 | Recitation Pattern の理論的根拠 |
Manus 論文の位置付け
Manus 社(汎用 AI エージェント企業、2025 年に Meta が買収)が公開した Context Engineering 論文は、業界標準テキストとして広く参照されています。Part 1(2025/7)では KV-Cache 最適化を含む 6 原則、Part 2 相当(2025/12 の Philipp Schmid 記事)では Compaction vs Summarization の区別、Context Rot 概念、Agent Harness が提唱されました。ただし Manus は コーディング寄りの汎用エージェント であり、業務系ではそのまま適用できない原則もあります。詳細は 補章 C「業界研究の業務系翻訳」 をご参照ください。
本シリーズの業界での位置付け
Context Engineering の概念は 2025 年以降急速に体系化されてきましたが、英語圏・日本語圏ともに業務系エージェント前提でフレームワーク実装まで踏み込んだシリーズは希少です。
海外の主要文献との比較
| 観点 | 本シリーズ | Anthropic 公式 | LangChain Blog | Manus 論文 | Microsoft 公式 ai-agents |
|---|---|---|---|---|---|
| 4 戦略(Write/Select/Compress/Isolate) | ✅ | ✅ | ✅ 発祥 | 部分 | ✅ |
| Manus 6 原則の解説 | ✅ | 部分 | ❌ | ✅ 発祥 | ❌ |
| 業務系制約(PII / 監査 / GDPR) | ✅ | 部分 | ❌ | ❌ | ❌ |
| マルチテナント分離 | ✅ | ❌ | ❌ | ❌ | ❌ |
本シリーズの 3 つの独自性
- 業務系翻訳の視点:Manus 論文や Anthropic 公式の原則は コーディング Agent 前提で書かれていますが、本シリーズはこれを PII / 監査 / マルチテナント / GDPR の制約下で実装可能な形に翻訳しています(補章 C で体系化)
-
MAF + C# の実装深度:英語圏でも Microsoft Agent Framework(MAF)の Skills 機能を解説した記事は数本程度。本シリーズは
AIContextProviderを含む独自実装まで踏み込んでいます - 3 ツール横断比較:VS Code Copilot Chat / Claude Code / Codex CLI の主要 3 ツールの実装を設計観点ごとに比較し、業界横断のベストプラクティスを抽出しています
「業界標準を盲目的に実装する」のではなく、「業界研究を批判的に読み、業務系の制約に翻訳する」という姿勢が本シリーズの核となります。
6. 📚 本書の構成
本書は以下の構成になっており、基本的には、第 1 回から順に読み進めることを想定していますが、可能な限り独立して記述するようにしていますので、気になる・あるいは不足していると感じる回のみを参照頂いても大丈夫です。
| テーマ | 記事 | 論点 |
|---|---|---|
| 設計の前提 | 第 1 回 | 7 つの設計観点と本書全体の構成を概観します |
| ランタイム制御 | 第 2～5 回 | LLM 呼び出しごとに動的に何が起きるかを扱います |
| エージェントの自己状態管理 | 第 6～7 回 | セッションを跨いでエージェント自身が状態を持つ仕組みを扱います |
| 宣言的ガバナンス | 第 8 回 | 組織・プロジェクトとしての標準化を扱います |
| 業界研究・最新動向（補章） | 補章 A・B・C | 本編の補足として業界動向・移行事例・業務系翻訳を整理します |
7. 💻 実装：Microsoft Agent Framework の位置付け
本書のコード例はすべて C# (.NET) + Microsoft Agent Framework (MAF) で記述します。
Python版とのAPI対比表は以下の通りです。実装時にはGitHub Copilotなどで変換して利用するようにしてください。
なおMAFのCompactionフレームワークは、2026年6月末時点ではexperimentalである点と、サンプルコードはPoC(概念実証)レベルである点に注意してください。
Microsoft Agent Framework の主要 API（早見表）
| 概念 | C# (.NET) API | Python 版 | 役割 |
|---|---|---|---|
| エージェント |
AIAgent / ChatClientAgent
|
ChatAgent |
エージェントの実体 |
| ツール定義 |
[Description] 属性 + AIFunctionFactory.Create
|
@tool デコレータ |
LLM が呼べる関数 |
| Context Provider | AIContextProvider |
ContextProvider |
LLM 呼び出し前後に context を差し込む |
| LLM クライアント抽象 |
IChatClient (Microsoft.Extensions.AI) |
chat_client |
LLM へのベンダー中立な抽象 |
| Compaction 戦略 |
Microsoft.Agents.AI.Compaction (MAAI001) |
agent_framework._compaction |
履歴圧縮 |
| Skills | AgentSkillsProviderBuilder |
SkillsProvider |
宣言的な能力定義 |
最小のエージェントコード
using Microsoft.Agents.AI;
using Microsoft.Extensions.AI;
using System.ComponentModel;
// 🔑 ツールは [Description] 属性で LLM への説明を付ける
// この説明文が LLM の「いつこのツールを使うべきか」の判断材料になる
public class FileTools
{
[Description("Read the contents of a file. Truncates at 2000 lines.")]
public string ReadFile(
[Description("File path")] string path,
[Description("Start line (1-indexed)")] int offset = 1,
[Description("Max lines")] int limit = 2000)
{
return File.ReadAllText(path);
}
}
public static class Example
{
public static AIAgent Build(IChatClient chatClient)
{
var tools = new FileTools();
// 🔑 AsAIAgent: IChatClient (LLM 抽象) を AIAgent に昇格する
// ChatClientAgentOptions で振る舞いを定義
return chatClient.AsAIAgent(new ChatClientAgentOptions
{
ChatOptions = new()
{
Instructions = "You are a helpful coding assistant.",
// 🔑 Tools は ChatOptions に登録する
Tools = new List<AITool> { AIFunctionFactory.Create(tools.ReadFile) },
},
});
}
}
8. 📊 ケーススタディ：主要 3 ツールの比較
本書は 主要 3 ツールの実装 の仕様を調査・比較し、各設計観点ごとに2026年6月末時点でのベストプラクティスとしてまとめています。このため特定ベンダーのみに依存するものではなく、また前述の通り今も試行錯誤中の領域である点にご注意ください。
| ツール | 提供元 | 本書での主な引用観点 |
|---|---|---|
| VS Code Copilot Chat | Microsoft | 本番テレメトリに基づく最適化、Memory、TODO 組み込み |
| Codex CLI | OpenAI | Compaction の理論的洗練、AGENTS.md 発祥 |
| Claude Code | Anthropic | SKILL.md 発祥、TODO V1→V2 移行、Task ツール |
上記の通り「どれか 1 つが秀でている」わけではなく、各ツールともに特徴がありますので、各ツールのいい点を取り入れながら設計してください。
9. 📖 本書の読み方
本書は全記事を通して同じ章立てで書かれており、「原則 → パターン → 設計判断 → 実装 → アンチパターン」という流れで、概念からコードまでを一気通貫で理解できるように整理しています。また各記事に「実装の方針と設計判断」の章を設け、なぜその実装を選んだのか、他の選択肢と比べてどうか、責務をどう分離しているかを先に押さえてから実装を読める構成としています。全章を通読する必要はなく、下表を目安にご自身の役割に合わせて重点を変えて読み進めてください。
| 章 | 内容 | 初心者 | 経験者 | アーキテクト | 開発者 |
|---|---|---|---|---|---|
| 🎯 本記事を読むべき人 | 想定読者と前提知識 | ◎ | ○ | ○ | ○ |
| ⭐ 原則 | なぜそれが重要なのか、根拠となる考え方 | ◎ | ◎ | ○ | ○ |
| 📐 パターン | 業界でよく見られる実装パターン | ○ | ○ | ◎ | ◎ |
| 💡 実装の方針と設計判断 | コードを読む前の設計意図の説明 | ○ | ○ | ◎ | ◎ |
| 💻 実装 | C# / MAF のサンプルコード | ◎ | △ | ○ | ◎ |
| ⚠️ アンチパターン | やってはいけないこと | ○ | ◎ | ◎ | ◎ |
凡例：◎ 重点的に読む／○ 通読推奨／△ 必要に応じて参照
ロールの目安：
- 初心者：エージェント開発経験 0〜3ヶ月
- 経験者：基本概念を既に知っており実務経験がある
- アーキテクト：設計判断やレビュー、方針決定を担う立場の方
- 開発者:実際にコードを書く立場の方。実装パターンとサンプルコードを重視
おわりに
本記事では、AI エージェントを本番運用するための「Context Engineering」の重要性と、本シリーズの構成を概説しました。7 つの設計観点はそれぞれ独立した指針を取り扱いますが、どれか 1 つでも欠けると本番運用が成立しなくなります。シリーズ全体を通じて体系的に学ぶことをお勧めします。
次回(第2回)は、コンテキスト管理の最初の防波堤となる 「ツール設計」 を取り上げます。
「ツール出力こそが Context Engineering の主戦場」
ツール定義の 7 つのベストプラクティス（ハードリミット、メタデータ完全性、description の書き方、件数キャップ時の選択基準、ReDoS 対策、Cache-friendly な順序設計、Mask Don't Remove）を、Microsoft の grep_search 最適化（-55% トークン削減を A/B で実証）の事例と共に解説します。
引き続きお読みいただければ幸いです。
🔖 用語集
| 用語 | 意味 |
|---|---|
| Context Engineering | LLM のコンテキストに何を入れるか・どう加工・維持するかの設計と運用 |
| 設計観点 (Design Perspective) | 本書で Context Engineering を分解する際の単位。互いに独立した 7 つの観点で構成され、全観点の網羅が本番運用の条件となる。 |
| Lost-in-the-Middle | LLM がコンテキスト中盤を読み飛ばす現象（モデルにより強度が異なる） |
| Context Rot | コンテキスト長の増加で性能が単調低下する現象（最新モデルでも観測） |
| Compaction | 履歴を圧縮する技術（Reversible が望ましい） |
| Summarization | 履歴を要約する技術（Irreversible、最後の手段） |
| Drift（ドリフト） | エージェントが本来のタスクから脱線する現象 |
| Recitation | 計画を末尾に再掲することで attention を維持するパターン |
| Agent Harness | LLM の周辺で context 管理・ツール実行を担うソフトウェア層 |
| MRCR v2 | 長文脈リトリーバル能力を測るベンチマーク（needle-in-haystack 型） |
| MAF | Microsoft Agent Framework |
| MCP | Model Context Protocol（ツール定義の業界標準） |
AGENTS.md |
プロジェクト固有指示の標準ファイル（Linux Foundation 標準） |
SKILL.md |
再利用可能な能力をパッケージ化する標準ファイル |
| Agent Scratchpad | 現在セッション内の情報をコンテキストウィンドウ外に保存する仕組み(Microsoft ai-agents-for-beginners で用いられる用語) |
| Runtime State Objects | 複雑タスクのサブタスク結果を段階的に格納するランタイム状態オブジェクト |
| RAG (Retrieval Augmented Generation) | 外部の知識ベースから情報を検索し、LLM のコンテキストに追加する手法 |
参考文献
学術論文
- Liu, N. F., et al. (2023). "Lost in the Middle: How Language Models Use Long Contexts." Transactions of the Association for Computational Linguistics. arXiv:2307.03172
- Mehta, A., & Datta, A. (Snowflake AI Research, 2026). "Plans Don't Persist: Why Context Management Is Load Bearing for LLM Agents." arXiv:2606.22953
業界研究レポート
- Chroma Research (2025/7/14). "Context Rot: How Increasing Input Tokens Impacts LLM Performance."
- Drew Breunig (2025/6/22). "How Long Contexts Fail" — Four Failure Modes of Context
Manus 論文・解説
- Manus AI / Yichao "Peak" Ji (2025/7/18). "Context Engineering for AI Agents: Lessons from Building Manus" (Part 1)
- Philipp Schmid (2025/12/4). "Context Engineering for AI Agents: Part 2"
- Lance Martin (2025/10/15). "Context Engineering in Manus" — LangChain × Manus Webinar 解説
- 0h-n0 TechBlog (2026/4/17).「Manus Engineering 解説: AIエージェントのための Context Engineering — 本番環境で得た実践的教訓」
Anthropic 公式
- Anthropic Engineering (2025/9/29). "Effective context engineering for AI agents."
-
Anthropic Research (2023/9/23). "Prompt engineering for Claude's long context window."
- 補足: 最新のプロンプト設計ガイドは Claude Platform Docs「Prompting best practices」 も参照。
OpenAI 公式
-
OpenAI (2026/4/23). "Introducing GPT-5.5."
- 補足: 安全性詳細は GPT-5.5 System Card を参照。