# AI エージェントの作り方：ops チーム向け 4ステップ実装ガイド URL: https://commandergpt.app/ja/journal/how-to-build-ai-agent-ops-workflow Type: blog Locale: ja Published: 2026-09-02 Updated: 2026-09-03 --- > AI エージェントをゼロから構築し、ops ワークフローに組み込む最短ルート。Pythonフレームワークやエンジニアリング主導の実装は不要。Ops リード向けの実践ガイド。 AI エージェント 作り方 ops ワークフロー 自動化の実装ガイド。Pythonフレームワークも 6 週間のスプリントも不要。シンプルな 4 ステップパターン：タスク定義→コマンドチェーン→コンテキスト統合→ループキャップ。Ops リード向けなら、アイデアから動作するエージェントまで 4 時間が現実的だ。 動作確認済みの実装をここに記す。 ## AI エージェントとプロンプトの違い プロンプトは一度だけ応答して止まる。エージェントはループする。タスク受け取る→ツール選択→出力読む→次のツール選択→完了まで続行。 Sales ops リードの視点で見れば、その差は明らか。プロンプトなら、URL 貼り付けで企業サマリーが一度だけ返ってくる。エージェントなら、CRM キューから企業名を引っ張ってきて、公開データ取得して、前回通話メモをチェックして、3 バレット程度の提案資料を書いて、ミーティング準備ドキュメントに放り込む。同じモデル、まったく別の実運用パワー。 Ops レベルのエージェントに必要なのは、リフレクションループもマルチエージェントオーケストレーションも不要。3 つだけ必須：入力定義、固定ツールシーケンス、明確な終了条件。ここから始めよう。 ![AI agent decision loop visualization with interconnected nodes](https://fdzlnqpwsaniezitwiuw.supabase.co/storage/v1/object/public/cms-media/commandergpt/2026-09/e236b4-inline1.webp) ## ステップ 1：エージェントが専有する 1 つのタスク定義 **30 秒で決める。** Workflow Builder を開く前に、タスクを 1 文で書く。1 文に収まらなければ、そのタスクはまだ自動化の準備ができていない。 OK：「企業名から LinkedIn + ニュース記事 + 前回通話メモを取得し、3 バレットの提案資料を生成」 まだ準備不足：「パイプラインを整理したい」 週 10 回以上やっていて、入力形式と出力形式が予測可能なタスク。Deal research 前のブリーフィング。リード一覧からの適格性判定。CRM からの週間メトリクス集計。CS ハンドオフ前のサマリー。 1 つ選ぼう。最初から全部自動化したい欲望に抗おう。動作するエージェントを 1 日で出すチームは、最小の有用なループから始める。3 週間フレームワークにはまるチームは、いまだにタスク選定中だ。 実用的なフィルタ：新人アナリストに明確なブリーフを渡して任せられるなら、そのタスクはエージェント適合性がある。判断が必要なら、まだ早い。 ## ステップ 2：コマンドをワークフローにチェーン CommanderGPT Workflow Builder を開く。UI は直線キャンバス：各ブロックがコマンド、各矢印がステップ間のデータ流。 Deal research エージェントなら、チェーンはこうなる： - `/research` + 企業名 → 企業規模、最新ニュース、既知の課題を構造化サマリーで返す - `/summarize` + research 出力 → 150 ワードに圧縮、ボイラープレート削除 - `/draft-email` + summary + 営業担当者名 → 最新ニュース記事への言及で始まるアウトリーチ一行目を生成 3 コマンド、1 ワークフロー、ゼロ摩擦。全チェーンは企業あたり 40 秒以下で完了。BDR チームが週 30 企業回すなら、営業担当者 1 人あたり週 90 分程度の準備時間を取り戻す。 チェーン設計の 2 ルール： **1 つのジョブに 1 コマンド。** Research と draft を 1 つの `/mega-research` コマンドに詰め込まない。小さいコマンドは出力が間違ったときのデバッグが楽だし、別のワークフローで再利用できる。 **データ渡しに名前をつける。** Workflow Builder の各ブロックには名前付き出力変数がある。`account_brief`、`compressed_summary`、`outreach_draft` みたいに呼ぼう。夜 11 時の QBR 前にぶっ壊れたとき、どのステップが落ちたか一目瞭然。 ![Slash command palette in a developer terminal for AI workflow automation](https://fdzlnqpwsaniezitwiuw.supabase.co/storage/v1/object/public/cms-media/commandergpt/2026-09/1572bf-inline2.webp) ## ステップ 3：コンテキスト、メモリ、CRM データを接続 コンテキストなしのコマンドチェーンは、単に高速なプロンプトでしかない。そのアカウントの履歴を知ってる人から出たような出力。それがコンテキスト。 CommanderGPT の 30 日間メモリ機能なら、`/research` コマンドは前回の同じアカウントとの通話、その営業担当者が送ったメール、HubSpot や Salesforce の同期済み CRM メモを拾える。手動で配線不要。Workflow Builder の設定パネルでコンテキストソースを定義すれば、コマンドは自動で引っ張ってくる。 ミーティング準備なら、ワークフローに通話メモ入力を組み合わせよう。チーム が AI 音声録音を使ってメモを取ってるなら、前回通話トランスクリプトをステップ 1 のコンテキストブロックに流す。エージェントが生成する提案資料は、前回通話で何が言われたかを参照する。それが、ジェネリック企業サマリーと実用的なプリコール提案資料の差だ。 **何を入れるか、何を省くか。** コンテキストが多いほど良いわけではない。入手可能な全 CRM フィールドを接続してから、無関係なデータポイント間の幻覚つながりを見守る。これはよくある落とし穴。入れるべき：最終相互作用日、前回通話メモ、オープン機会ステージ、既知の異議。省く：請求履歴、3 年前のサポートチケット、2024 年に更新を止めたフィールド。 テスト方法：よく知ってる 5 つのアカウントでワークフロー実行。出力がアカウント履歴を読んだ人っぽい感じなら、コンテキスト量がちょうどいい。すべてを留保するなら、入力にノイズが多すぎる。 ## ステップ 4：本番前に guardrails を設定 このステップはほとんどのチームが飛ばす。デモは素晴らしく見えたし、QBR は明日だから。 本番運用前に、2 つの guardrail は絶対必須。 **ループをキャップ。** Workflow Builder はすべてのワークフローに `max_steps` 設定がある。3 ステップチェーンなら 10～15 に設定。守備範囲外の入力でエージェントがループし続けると、月間トークン予算を全部焼く。15 が大概；3 ステップチェーンで 8 を超えたらアラート設定。 **取り消し不可の操作には承認ゲート。** ワークフロー最終ステップが Slack にメール送信や投稿するなら、draft と send の間に人間確認ステップを入れてくれ。自明だと思うだろ。違う。何個かのチームが Workflow Builder の自動補完で `/draft-email` を `/send-email` に接続してしまい、意図せず 200 アカウントに通知を送った。その 1 回の不正アウトリーチコストは、確認ステップの 3 分よりずっと高い。 20 回ワークフロー実行して確認ゲート通して出力が一貫して良けりゃ、ゲート削除してもいい。それより前じゃない。 ![Minimalist ops workspace with laptop showing workflow diagrams](https://fdzlnqpwsaniezitwiuw.supabase.co/storage/v1/object/public/cms-media/commandergpt/2026-09/ce1ac2-inline3.webp) ## Ops エージェントが最初の週で失敗する理由 失敗パターンはコマンドエラーじゃなく、コンテキスト腐敗。ほぼ毎回。 ワークフローは月曜日に完璧。木曜日には CRM 統合が 48 時間同期遅延してるのに誰も気づかずに古いデータを拾ってる。エージェントはこれを教えない。Q3 通話メモじゃなく火曜日の通話を参照する提案資料を、静かに黙って吐き出す。 原則：すべてのワークフロー最初ブロックにコンテキスト鮮度チェック入れろ。単純な `/check-context-age` コマンドで最終同期タイムスタンプ返す。データが 24 時間より古いなら、ワークフローは黙らず警告出す。 2 番目の失敗パターンはプロンプトドリフト。5 月に `/research` コマンド設定。8 月に ICP がシフト、アウトリーチフォーマットが変わった、営業チームの新しい異議処理テンプレートできた。コマンド実行するけど、出力フォーマットは誰も使ってない。6 週間ごとに 15 分ワークフロー review を予約。最後 10 出力を現在のプレイブック対で読む。ズレてたらコマンドプロンプト更新。 3 番目は内部からのスコープクリープ。誰かが 4 番目コマンド追加。出力ほぼ正しかったから。それから 5 番目。週 3 で、ワークフロー 8 コマンド、レイテンシ 1 企業 3 分、誰も何の出力フィールドかわかんない。チェーン 3～5 コマンド。それ以上必要なら、2 つのワークフロー共有出力フォーマットで分割。 ## 今すぐフォークするプレイブック CommanderGPT テンプレートライブラリから複製して、今日から使えるワークフロー。 **ワークフロー：Deal Research + Outreach Draft** - 入力：企業名（CRM から貼り付けるか直接タイプ） - ステップ 1：`/research` + 企業名 + コンテキストソース：前回通話メモ、機会ステージ - ステップ 2：`/summarize` 形式制約付き：「3 バレット、各 50 ワード以内、最新ニュース記事が先頭」 - ステップ 3：`/draft-email` トーン指定：「直接的、最初の行で特定ニュース記事参照、フィラー開き文なし」 - 出力：ブリーフィングブロック + メール draft、クリップボードにコピー - 人手確認ゲート - `max_steps`: 12 このテンプレートをフォーク、CRM 統合を接続、よく知ってる 3 企業で実行、出力をチーム現在の手作業産物と比べる。デルタが 80% 品質マッチ以下なら、修正はコマンドじゃなくコンテキストソースにある。 ワークフロー発火。出力読む。出す。 2026 年で AI エージェントから最高の効果が出てるチームは、最高のマルチエージェント パイプラインを構築したやつじゃない。週 1 で動く 3 コマンドチェーン出してから、そこから反復したやつだ。アーキテクチャはあとで進化する。出すという習慣は待てない。 ## FAQ ### AI エージェントと従来の自動化の違いは何ですか？ 従来の自動化は固定ステップの実行です。エージェントは各ステップで判断し、必要に応じて次のツールを選択する能力を持ちます。Ops コンテキストでは、従来の自動化は IF-THEN ルール（〇〇なら XX を実行）、エージェントはタスク目標から逆算して最適なツール選択を動的に決める違いです。 ### CommanderGPT のワークフロービルダーはコーディングが必要ですか？ 不要です。Workflow Builder はノーコード UI です。ブロック（コマンド）をキャンバスにドラッグして矢印で接続。データ変数名をつけるだけ。Python や API 統合知識は必須ではありません。 ### コンテキスト腐敗をどう検知しますか？ 各ワークフロー最初ブロックに `/check-context-age` を入れて、最終同期タイムスタンプを出力。24 時間以上古いなら、警告を出すか実行を中断。定期的にワークフロー出力をサンプル確認（5 件程度）して、出力が最新データ反映してるか目視チェック。 ### エージェントが無限ループに入ったら？ Workflow Builder で `max_steps` 設定してください。3 ステップチェーンなら 12～15。これを超えたら自動停止。月間トークン焼きを防ぐため、アラート設定も忘れずに。 ### CRM 統合が遅れてる場合、どうしますか？ 48 時間以上の同期遅延が既知なら、コンテキストソースから該当フィールド除外。あるいは、手動で前回メモを Slack スニペットにペーストしてワークフロー入力に含める。コンテキスト新鮮さより、古い情報を黙って使うリスクのほうが大きい。 ### ワークフローチェーンは何コマンドが最適ですか？ 3～5 が実用的。3 ステップなら 90 秒以下。8 コマンド以上は各ステップ結果の追跡が困難になり、メンテナンスコスト急上昇。複数ステップ必要なら、共有出力フォーマットで 2 つのワークフローに分割。 ### エージェント出力を本番運用前に確認する期間は？ 確認ゲート通して最低 20 回。メール送信など取り消し不可操作は、人手確認で 20 回。出力品質が一貫してたら確認削除可。3 週間で毎日 3 企業なら 20 回は達成。