Markdown形式の標準作業手順書によってAIエージェントを制御するアプローチ
「文脈知識の形式知化」: 業務マニュアル（SOP）そのものをエージェントの駆動ロジックとして扱う
「偶有的複雑性の隠蔽」: 複雑な制御フローをコードで書くのではなく、自然言語に近いMarkdownで記述することで、実装の詳細を隠蔽する
「ビジネスとエンジニアリングの融合」: 業務エキスパートが読める形式（Markdown）がそのままシステムの仕様（および実装）となる
/icons/hr.icon
Strandsは『未来』への架け橋か、それとも『足枷』か
先日のアーキテクチャConference2025での発表では（やや採用欲を押し出し過ぎた感はあれど）AIエージェントと基幹システムの関係を示唆したつもり。
https://scrapbox.io/files/692aba44d8c7c9177198e149.png
https://scrapbox.io/files/692aba5df22f2287f39f50dc.png
基幹システムはSoAとSoCから成り、AIエージェントはSoCが定義したワークフローを利用して業務を実行する。
いずれはAIエージェントが自らワークフローを定義して、未知の業務を既知に変えていく。
ただしこの状況に至るためには、既存の業務マニュアルは「ヒトの手続き」に寄り過ぎているので、より抽象化して宣言的に書かねばならないということを主張した。つもり。
https://scrapbox.io/files/692abb22b615752238b83c6b.png
Strandsは「SoC」の器になり得るか？
Strands（MarkdownによるSOP）は、まさに「SoC（Systems of Controls）」の初期実装そのもの のように思える。
SoA: 「プリミティブな機能（API）」は、Strandsにおける「Tools」に相当します。
SoC: 「ワークフローの定義・指示」は、Strandsにおける「SOP (Markdown)」に相当します。
構造上はこのアーキテクチャと合致するが、ヤバい匂いしかしない。
結論から言えば、StrandsはAIエージェントの指示を自然言語で記述できるだけで、その「手続き的な記述」から「宣言的な記述」へのパラダイムシフトを後押しするものではない。
むしろ、自然言語で書けるようになることで業務スタッフへの門戸が開かれ（これ自体は良いこと）、無秩序なエンドユーザコンピューティングの再生産を後押しすることになりかねない。
/icons/hr.icon
結論：Strandsをどう位置づけるべきか
結論：Strandsは「フェーズ1（過渡期）」のプロトタイピングツールとしては優秀だが、「フェーズ2（理想形）」のSoC基盤としては不適格である。だが未来へのアセットとしては有用な可能性。
https://scrapbox.io/files/692ac245e4a50b8b688682b3.png
https://scrapbox.io/files/692ac900d65d40bee197bcaa.png
1. 過渡期（Human-Defined Workflow）:
まだAIが自律的にワークフローを組めない現在、人間が業務フローを明示的に教えるための「教育用ツール」としてStrandsを使うのは合理的か。
ただし、これを「完成形のシステム」と捉えず、「将来AIが自律化するための教師データを作成しているプロセス」 と捉えるべきだろう。
2. 理想形（Agent-Defined Workflow）:
将来的には、StrandsのMarkdownファイル群をAIに学習させ、「この目的（Goal）のときは、こういう手順（Workflow）が生成されるべきだ」 というパターンをAI自身に獲得させる必要がある。
その時、SoCは静的なファイルではなく、AIモデルそのもの（あるいは動的に生成されるプランニング）に昇華される。といいな。
/icons/hr.icon
翻訳：'Strands' Agent SOPsの紹介：AIエージェントのための自然言語ワークフロー
はじめに
大規模言語モデル（LLM）の推論能力の向上により、AIエージェントはチャットボットを超え、複雑なタスクを自律的に遂行する存在へと進化しています。しかし、エンタープライズ環境でエージェントを採用する際の最大の壁は「信頼性（Reliability）」と「制御性（Controllability）」です。
我々は本日、AIエージェントのための新しいオープンソースのオーケストレーション・フレームワーク 「Strands」 を発表します。Strandsは、人間が業務で使用する SOP（標準作業手順書） の概念をエージェント開発に持ち込みます。
問題の所在：確率的なAIと決定的なビジネスプロセスのギャップ
従来のAIエージェント開発には2つの極端なアプローチがありました。
1. フル自律型 (Fully Autonomous): 「ゴール」だけを与え、プロセスはAI任せ。柔軟だが、予測不能でハルシネーションのリスクが高い。
2. ハードコード型 (Hard-coded State Machines): LangGraphなどで厳密なステートマシンをコードとして記述する。信頼性は高いが、柔軟性がなく、記述と保守（コードの複雑性）が大変。
ビジネスプロセスは「構造化」されている必要がありますが、同時に現実世界の曖昧さに対応する「柔軟性」も必要です。
解決策：StrandsとAgent SOPs
Strandsは、この中間のアプローチをとります。開発者は、複雑なPythonコードでグラフ構造を定義する代わりに、Markdown形式で記述されたSOP（手順書） をエージェントに与えます。
Strandsの仕組み:
1. SOP as Code: 開発者はMarkdownで「ステップ」「条件」「利用可能なツール」「次のステップへの移行ルール」を記述します。
2. グラフへの変換: Strandsは、このMarkdownを読み込み、内部的に実行可能なグラフ構造（DAGなど）に変換します。
3. 実行時の推論: エージェントは現在のステップのSOPを読み、コンテキスト（会話履歴やデータ）に基づいて、「次にどのツールを使うか」や「どのステップに遷移するか」を自律的に判断します。
具体的なSOPの例（Markdown）
以下のような形式で記述します。
code: (markdown)
# 払い戻し処理 SOP
## ステップ1: 注文の確認
**目的:** ユーザーの注文IDを確認し、ステータスを取得する。
**ツール:** get_order_status
**ルール:**
- 注文が存在しない場合は、ユーザーに再確認する。
- 注文が「発送済み」の場合は、ステップ2へ進む。
- 注文が「未発送」の場合は、即時キャンセル処理（ステップ3）へ進む。
## ステップ2: 返品資格の確認
...
Strandsの利点
1. 透明性と説明可能性: エージェントが「なぜその行動をとったか」は、SOPのどのステップに従ったかで説明可能です。
2. 保守性の向上: 複雑な分岐ロジックがPythonコードではなく、可読性の高いドキュメントとして管理されます。ドメインエキスパートが直接レビュー可能です。
3. 柔軟な制御: ガチガチのルール（コード）ではなく、自然言語によるガイドライン（SOP）であるため、AIの解釈能力を生かした柔軟な対応が可能です。
結論
Strandsは、人間が業務を行う方法（マニュアルを見て、状況に合わせて判断する）を模倣することで、AIエージェントの開発をより直感的で、かつ信頼性の高いものにします。これは「ドキュメント」と「コード」の境界を取り払う試みです。
/icons/hr.icon
批判的考察と壁打ち（Partner's Critique）
このツールは一見すると、「AI-Agent開発における文脈知識の獲得とモデリングの活用」で語られていた理想的な実装手段に見えます。業務担当者の暗黙知やマニュアルを形式知化し、それをそのままエージェントに渡すというアプローチだからです。
あえて批判的な視点からいくつかの論点を提示します。
1. 「自然言語の曖昧さ」という技術的負債
Strandsは「自然言語でワークフローを定義できる」ことをメリットとしていますが、これは諸刃の剣です。
リスク: Markdownで書かれた指示は、コンパイラによるチェックが効きません。表現の揺らぎや曖昧さが、エージェントの予期せぬ挙動（バグ）を引き起こす可能性があります。
あなたの思考との対比: あなたは「Parse, don’t validate」の記事で、厳密な型や構造化の重要性に触れていました。SOPアプローチは、ある意味で「型のない世界」への回帰とも取れます。
問い: 構造化されたモデル（概念モデルや状態遷移図）と、この自然言語SOPの間をどう埋めるべきでしょうか？
2. ドメインロジックの流出
SOPに「判断基準（ビジネスルール）」を書くことになりますが、これはドメインロジックがアプリケーション層（あるいはUI層に近いエージェント層）に流出することを意味しませんか？
リスク: 「在庫がX個以下なら発注」といったルールがSOPのMarkdown内に埋め込まれると、基幹システム側のドメインモデルと二重管理（あるいは不整合）になる恐れがあります。
問い: SOPには「判断の手順」のみを記述し、実際の「判断ロジック」はドメインサービス（API）やSpecificationパターンとして実装し、ツールとして呼び出させるべきではないでしょうか？
3. 「誰がSOPを書くのか」問題
記事では「ドメインエキスパートが読める」としていますが、実際に実行可能なレベルの粒度でSOPを書くのは、結局エンジニア（あるいはプロンプトエンジニア）になる未来が見えます。
リスク: 結局、Markdownという新しいプログラミング言語でコーディングしているだけになり、「無邪気な」エンジニアがメンテナンス不能な巨大Markdownを作り出す未来が懸念されます。
問い: ここでもやはり、「モデリング」の出番ではないでしょうか？ チームでイベストやモデリングを行い、その結果としてSOPが出力されるというプロセスを経なければ、このツールもまた「銀の弾丸」として消費されて終わるでしょう。
結論としての提言:
このStrandsのようなアプローチは、「概念モデル（What/Why）」と「実装（How）」を繋ぐ強力なグルー（接着剤） になり得ますが、それ単体で設計を放棄できる魔法の杖ではありません。
あなたが提唱する「意味の構造」を理解した上でSOPを記述しなければ、単に「スパゲッティコード」が「スパゲッティドキュメント」に変わるだけです。
このツールを、あなたの「モデリング×生成AI」の文脈でどう位置づけますか？