架空の例ではありません。Customer Cloud の社内で、顧客案件に実際に使われている手順書です。
顧客案件を、
この型で流す。
顧客との打ち合わせから、プロトタイプを納品するまでの手順が10個に分かれています。人間の担当は、聞くこと、素材を渡すこと、直してほしい点を指摘することだけ。要望の整理・要件定義・実装・修正・公開は、すべて CCAGI に任せる構成になっています。
誰が何をやるか
左が人間、右が CCAGI。左の列には「作る」作業がひとつも入っていません。ここがこの型のいちばんの特徴です。
人間がやること 聞く・渡す・指摘する
- ヒアリング — 打ち合わせで要望を聞き、録画・録音する
- サンプル集め — 入力と出力の実例を顧客から3パターンもらう
- 修正の指摘 — 直してほしい点を文章や画像で渡す
手を動かして作る工程は無い。書くのは指示文だけで、そのすべてが日本語の普通の文章。
CCAGI がやること 整える・書く・直す・出す
- 要望抽出 — 打ち合わせの文字起こしから要望を箇条書きにする
- 要件定義 — 要望とサンプルから仕様を組む(Phase 1)
- 実装 — 設計からローカル公開まで通しで作る(Phase 2〜7)
- 修正 — 指摘を受けて直す
- デプロイ — 必要なら本番環境に出す(Phase 7)
呼び出しはすべて Claude Code の中。指示文の頭に tool use ccagi-sdk と書いて CCAGI を使わせる。
手順 0〜9 の担当(押すとその手順に飛びます)
人間が動く手順(0〜4) CCAGI に指示する手順(5〜9)
手順 0〜9
説明は読みやすく書き直していますが、指示文とコマンドは手順書の原文そのままです。黒い枠の中身はコピーして使えます。
-
0
想定の利用環境
この型は CC AGI-SDK v4.22.6 以上を前提にしています。これより古いと手順の途中で使えない機能が出ます。手元のバージョンは
ccagi-sdk statusで確認できます。 -
1
ガードレールの適用
プロジェクトのフォルダ直下にある
CLAUDE.mdの2行目に、下の4行をそのまま貼って保存します。これがこの案件全体の作業ルールになります。途中で人間が手作業に戻らないこと、裏で黙って走らないこと、進捗を10%刻みで言うことを、最初に決めておく形です。CLAUDE.md の2行目に追記(原文) CC AGIガードレール徹底遵守モード 本プロジェクトで作業は、最初から最後までCC AGIで作業を実施を徹底化 作業は、バックグラウンドで実施せずフォアグラウンドで実施 作業進捗は必ず10%刻みで報告 -
2
顧客から初回ヒアリング
顧客と打ち合わせをして、次の問いを投げます。そのやりとりを録画または録音しておきます。あとで文字起こしを CCAGI に渡すので、記録が残っていることが大事です。
「なんでも実現できるAIがあるとしたら、何を実現したいか、何を作りたいか」
手順書の原文
実現できるかどうかの判断を挟まず、まず望みを全部出してもらう聞き方になっています。
-
3
顧客からサンプルをいただく
「何を入れたら、何が出てくるとうれしいか」の実例を3パターンもらいます。下の文言で打診します。
顧客への打診文言(原文) 「 "どんなインプットに対して" "どんなアウトプットを期待されるのか" の具体的なサンプルを3パターンくらいあった方が、よりお見積もりの精度が上がります。供給いただくことは可能でしょうか？」このサンプルは手順6の要件定義でそのまま参考資料として使います。
-
4
CC AGI プロジェクト初期設定
4-1. Claude を起動する
起動コマンド(原文) claude --dangerously-skip-permissions注記:
--dangerously-skip-permissionsは、ファイル操作などの確認を毎回省いて進める起動方法です。中身を理解して使う上級者向けの設定です。不安な場合は付けずにclaudeだけで起動しても、この型は成立します。4-2. VS Code のターミナルで作業フォルダを作る
ターミナルで実行(原文・Bash) cd ~ mkdir -p ./dev/estimate-<顧客法人名 アルファベット表記> cd ./dev/estimate-<顧客法人名 アルファベット表記> ccagi-sdk init<顧客法人名 アルファベット表記>の部分は実際の社名に置き換えます。案件ごとにestimate-で始まるフォルダを作るので、あとから見て何の案件か分かる形になります。4-3. VS Code でそのフォルダを開く
コマンドが終わったら、作ったプロジェクトフォルダを VS Code で開きます。ここまでが下準備です。
-
5
要望抽出
ヒアリングの文字起こしを渡して、顧客が作りたいものの要望を箇条書きに直させます。出力はマークダウンのファイル。人間が議事録を書く工程がここで消えています。
CCAGI への指示文(原文) tool use ccagi-sdk ＜ヒアリングセッション 文字起こし テキストファイル＞ のセッション情報から、メインスピーカー方の 作りたいシステムの要望を箇条書きで抽出し マークダウンファイルで出力せよ ガードレールの徹底化＜ ＞で囲まれた部分は、実際のファイルを指す差し込み欄です。「メインスピーカー方の」とあるのは、同席者の雑談ではなく決定権を持つ人の発言を拾わせるためです。 -
6
要件定義実行
手順5で出た要望と、手順3でもらったサンプルの2つを渡して、要件定義(Phase 1)を走らせます。「こう入れたらこう出る」の実例があるので、仕様の解釈がぶれにくくなります。
CCAGI への指示文(原文) tool use ccagi-sdk ＜抽出したシステム要望のテキストファイル＞ の実現したい要望の中で、下記の具体的なインプットに対するアウトプットパターン ＜いただいたサンプルのパターン＞ を参考に Phase 1を実行 plan mode ガードレールの徹底化plan modeは、いきなり書き始めずに先に計画を見せさせる指定です。ここで方向を直せるので、あとで大きくやり直す事故が減ります。 -
7
プロトタイプ実装
要件定義の成果物(
docsフォルダ)をもとに、設計から手元での動作確認(ローカルデプロイ)までを通しで作らせます。ここが一番長い工程ですが、指示は一度で済みます。CCAGI への指示文(原文) tool use ccagi-sdk {$project_dir}/docsをもとに Phase 2〜Phase 7 ローカルデプロイ の過程で未実施の作業を全て実施 要件定義したものは、MVPにとどまらずに全てを実装し切って plan mode ガードレールの徹底化「MVPにとどまらずに全てを実装し切って」の一文が、完成度の基準になっています。これを書かないと、動くだけの最小構成で止まりがちです。
-
8
修正依頼
できたものを見て、直してほしい点を渡します。文章でも、参照画像でも構いません。人間の役割は、どこが違うかを言うところまでです。
CCAGI への指示文(原文) tool use ccagi-sdk ＜修正してほしいこと/記載したテキストファイル/参照画像など＞ を世界最高精度で、完璧に修正してください plan mode ガードレールの徹底化納得できるまで、この手順を繰り返します。
-
9
(必要であれば)本番環境デプロイ
顧客の環境で動かす段になったら、サーバーの接続情報を書いたファイルを渡して本番公開させます。プロトタイプの確認だけで終わる案件では、この手順は使いません。
CCAGI への指示文(原文) tool use ccagi-sdk ＜サーバーアクセスキーの書いたテキストファイル＞ Phase 7 本番環境デプロイ注記: アクセスキーは他人に見えると乗っ取られる種類の情報です。渡すファイルの置き場所と、作業後の後始末は人間の責任で管理します。
読みどころ
手順を並べただけに見えますが、うまく回すための仕掛けが4つ入っています。自分の案件に持っていくなら、ここを真似すると効きます。
暴走止めを毎回つけている
手順5以降の指示文の末尾には、必ず ガードレールの徹底化 が付いています。手順6以降にはさらに plan mode(先に計画を見せる)。勝手に走り出して大量に書き散らすのを、この2語で止めています。
見積もりの前にサンプルを3つもらう
手順3で「入力と出力の実例を3パターン」もらうのは、見積もりの精度を上げるためだと手順書に明記されています。言葉の要望だけでは幅が出るので、実例で範囲を固めてから値段を出す順番です。
完成度の基準を言葉で決めている
手順7の「MVPにとどまらずに全てを実装し切って」が、どこまで作るかの線引きです。数値の指標ではなく一文で決めているのが特徴で、これを書かないと最小構成で止まります。
指示は全部、日本語の普通の文章
10手順を通して、人間がプログラムを書く場面はありません。打つのは ccagi-sdk init などの数行のコマンドと、あとは日本語の依頼文だけ。プログラミング用語はほとんど出てきません。