AI エージェントが向いているのは「クリエイティブ」な作業だけ？
皆さんは、AI エージェントを使っていますか？
私の場合は、プライベートで Claude Code と Kiro を使っています。
使い道としては、コード生成からトラブルシュート、資料作成など、何でもです。
正直、もう AI エージェントのいなかった時代には戻れないと思っています。
それはさておき、恐らく多くの方が AI エージェントに期待している事は、以下の2種類ではないでしょうか。
- コード生成やアプリケーション開発、資料作成のようなクリエイティブな業務をサポートする
- 日々発生する定型作業を自動化する
前者については、これまでに様々な手法が研究され、そこそこ上手く行くようになっています。
しかし、後者についてはまだまだ課題が多いという印象でした。
何故なら、クリエイティブな作業では(目的を達成できるなら)どんな成果物でも許される場合が多く、後者は毎回必ず同じ成果物を求められるからです。
こんな状況を変えるべく、AWS が発表したのがStrands Agents SOPsです。
※ 標準手順の概念自体は Anthropic の Skills コマンドで既に登場していましたが、今回のアップデートにより、MCP を持つあらゆるエージェントで利用出来るようになりました。
この strands-agents-sops ですが、大きく以下のポイントがあります。
- Agent SOP というフォーマットで記述する
- Agent 自身が、必要なタイミングで手順書をロード出来るようにする
この2つについて、詳しく解説します。
ポイント1: Agent SOP というフォーマットで記述する
Agent SOPとは、一言で言うなら AI エージェントの為に用意された作業手順書です。
本手順書を使う事で、異なる AI システムやチーム間で連携可能なワークフローとして AI エージェントを動かせるようになります。
AI エージェントの動作を固定する為、文法にいくつか特徴があります。
- 自然言語で記述する
- 作業に必要な入力をパラメータ化する
- RFC 2119 の文言(MUST, SHOULD, MAY)を使って、制約を定義する
# SOP Name ## Overview Brief description of what this SOP accomplishes and when to use it. ## Parameters - **required_param** (required): Description of required input - **optional_param** (optional, default: value): Description with default ## Steps ### 1. Step Name Description of what this step accomplishes. **Constraints:** - You MUST perform required actions - You SHOULD follow recommended practices - You MAY include optional enhancements ## Examples Concrete usage examples showing input and expected outcomes. ## Troubleshooting Common issues and their solutions.
特に、RFC で定義された文言で制約を設定する事が重要です。
まだ検証していませんが、この文法の為、英語で記述した方が上手く動作するかもしれません。
これらのポイントを踏まえて手順書を作成する事で、AI エージェントの作業を固定できます。
ポイント2: AI エージェント自身が、必要なタイミングで手順書をロード出来るようにする
strands-agents-sops は MCP サーバとして動作し、AI エージェントの要求に合わせて手順書を返却します。
実際にどう動くのか、MCP Inspectorで動作を確認してみました。
1. ListPrompt で、利用可能なプロンプトの一覧を取得する:
AI エージェントが ListPrompt を実行すると、登録されているプロンプトの一覧を取得出来ます。
これによって、AI エージェントが、どんな手順書が用意されているのか、いつ使えばいいのかを理解できます。
2. GetPrompt で、プロンプトの全文を取得する:
少々見切れて見づらいですが、一覧から特定のプロンプトに対して GetPrompt を実行すると、以下のように手順書の全文を読み込むことが出来ます。
これによって AI エージェントは、自分の任意のタイミングで手順書の全文を取得出来るようになります。
(補足) 詳細な挙動
ソースコードを確認したところ、以下の仕様が分かりました。
- strands-agents-sops
--sop-paths で MCP を起動した際、## overview セクションだけを切り抜いて prompt に格納する - prompt を get する際、agent-sop タグでラップして返却する
<agent-sop name="{sop_name}">
<content>
{sop_content}
</content>
<user-input>
{user_input}
</user-input>
</agent-sop>
これによって、気合いで MCP プロンプトとして利用しているようです。
なので、overview セクションは手順の使い方が分かるよう、しっかり書く必要がありそうです。
Claude Code の場合は、yaml フォーマッタで文頭に書かれたskill 名称と解説をロードしているので、どちらも似たような実装ですね。
動的なコンテキストのロードは、コンテキストエンジニアリングの観点から非常に重要
trands-agents-sops で最も重要な点は、後者の「動的なコンテキストのロード」を実現している点にあります。
大前提として、AI エージェントの記憶力には限界があり、無限にテキストを読み込ませる事は出来ません。
理由は以下の2つです。
1. コンテキストサイズが決まっている:
AI エージェントで利用している LLM によって、一度に利用出来るトークン数が決まっています。これをコンテキストサイズと呼びます。
なので、AI エージェントを利用する際はコンテキストサイズを超えないよう、意識する必要があります。
2. コンテキスト腐敗(context rot)に注意が必要:
コンテキスト腐敗とは、コンテキストが長くなればなるほど LLM の精度が落ちる現象です。一言でまとめると、コンテキストが長くなるにつれて、情報を取りこぼす可能性が上がります。
コンテキストエンジニアリングではコンテキストの制御の手法として以下の4つを挙げています。
- write context: AI エージェントにメモを取らせる
- select context: AI エージェントにコンテキストを選択させる
- compress context: 必要に応じてコンテキストを圧縮する
- isolate context: コンテキストを分離する
つまり、strands-agents-sops は2つ目の”select context”を実現するツールなのです。
strands-agents-sops を活用する際のコンテキスト例
strands-agents-sops を活用する際のコンテキスト管理として、以下のようなパターンが考えられます。
- IaCコード群/
- sops/
〇reboot-server.md: サーバ再起動手順
〇restart-process.md: プロセス再起動手順
〇analyzing-logs.md: ログ分析手順 - AGENTS.md: エージェント向けの環境情報と、エージェントの目的(例: トラブルシュート)
- README.md: 人間向けのプロジェクトの概要や目的などのまとめ
例えば、本ディレクトリで kiro-cli を起動すると、共通情報である AGENTS.md と README.md を読み込んで、プロジェクトの概要や環境情報を把握します。
次に、kiro に対してサーバ再起動を依頼すると、MCP を使って reboot-server.md を追加でロードします。
あとは、与えられた情報と手順を組み合わせて kiro がサーバ再起動作業を実施します。
このように strands-agents-sops は、作業に必要な情報だけを確実に読み込ませるツールとして非常に有効です。
人が SOP を書かなくて良いのもポイント
ここまで読んだ人は、恐らく「ゆーて Agent SOP を書くの自体が大変じゃん、、、」と思っているはずです。
心配不要です。
最近の AI エージェントにはコーディング規約を設定出来るものが多いです。
例えば kiro-cli なら、.kiro/steering 配下に md を配置すると、起動時に読み込んで規約として扱ってくれます。
ここに公式が用意している SOP の記述規約(https://github.com/strands-agents/agent-sop/blob/main/rules/agent-sop-format.md)を格納する事で、SOP を対話形式で作成出来るようになります。
「手順書は育てるもの」
SOP を人が作る必要はない、と書きましたが、もちろん注意事項はあります。
次の4つの観点を意識しながら SOP を作りましょう。
1. 手順の内容を評価する:
まず、エージェントによるタスク実行結果を評価する事が重要です。
エージェントにタスクを何度も実行させ、どこで苦労しているか、追加のコンテキストが必要かを確認しましょう。
2. 拡張性を考慮する:
フローがあまりに複雑になった場合、細かく分割しましょう。
SOP ファイルが大きくなりすぎると、読み込んだ際のコンテキストサイズが増えてしまい、動的ロードのメリットが損なわれてしまいます。
複雑な作業が必要な場合、スクリプト化で大体出来ないかも含めて、手順設計を見直しましょう。
3. AI エージェントの視点で考える:
AI エージェントが実際の作業でどうやって MCP やツールを活用しているのかを監視し、結果に基づいて SOP を改善しましょう。
4. AI エージェントに反復させる:
AI エージェントにタスクを実行させる際、成功事例とミスを md 内に記録するよう、コンテキストで指示しましょう。
これによって失敗した場合、自分で改善案を検討出来るようになります。
わたしの経験上、最初から完璧な手順書は存在しません。
何度もテストして、改善して少しずつ上手く動くようになるものです。
AI エージェントを活用しながら、自分たちの運用にあった手順書を育てる、くらいのつもりで作る事をオススメします。
最後に
いかがでしたか？
strands-agents-sops を通じて、新しい AI エージェントの活用方法をイメージ頂ければ幸いです。
Japan AWS Ambassadors アドベントカレンダー第二弾は、NIR 前原さんです。
ぜひ次回もお読みください！
以上、AWS Ambassador 濱田 一成がお送りしました！
出典
- Strands Agents SOPs: https://aws.amazon.com/jp/blogs/opensource/introducing-strands-agent-sops-natural-language-workflows-for-ai-agents/
- Github: https://github.com/strands-agents/agent-sop/tree/main
- Agent skills: https://www.anthropic.com/engineering/equipping-agents-for-the-real-world-with-agent-skills
- Context Rot: https://research.trychroma.com/context-rot
