「取引先の与信額を超えたら商談を登録できないようにしたい」と頼むと、トリガが返ってきます。入力規則1つで済む話です。動くので、レビューを通れば残ります。そして残ったコードは、以後ずっとテストクラスと保守の対象になります。

この種の失敗は、AIの性能の問題ではありません。何をどちらで作るかを、人が決めずに渡しているから起きます。

線引きを人が決めてから渡す

AIに「作って」と頼めば、コードが返ります。コードを書くのが得意だからです。宣言的な設定で足りるかどうかは、この組織の運用、既存の設定の積み重なり、将来の保守の担い手で決まる話で、依頼文の中には書かれていません。

だから、渡す前に人が判定します。判定は4つの問いで足ります。

4つ目が決定的です。Salesforce でAIに任せやすいのは、テストで確かめられる領域です。逆に、確かめ方が「画面で操作してみる」しかない領域は、任せたあとの検証が人の目視に戻るので、任せる効果が小さくなります。

任せやすいもの／任せにくいもの

「任せにくい」は「AIが間違える」という意味ではありません。 間違えたときに気づきにくい、または戻しにくい、という意味です。判断の軸は難しさではなく、やり直しが効くかです。

手順

① 設定で済むかを先に判定する

前節の4つの問いを通します。ここで「設定で足りる」と分かったものは、そもそもAIに実装を頼みません。頼むとしても、設定の手順を書かせるだけにします。

判定の時点で迷うものは、「両方の案と、それぞれの保守の負担を出して」と頼むのが有効です。案を選ばせず、比較を作らせて、選ぶのは人がやる。この形にすると、コードに寄る傾向を打ち消せます。

② 対象のメタデータを揃えて渡す

Salesforce は、同じ業務でも組織ごとに項目の参照名が違います。渡さないと、一般的な名前のコードが返ります。Account.CreditLimit__c のつもりで Account.Credit_Limit__c と書かれていると、動かないか、もっと悪い場合は別の項目を更新します。

渡すのは次の4つです。

• 対象オブジェクトと項目のAPI 参照名（型・必須・参照先まで）
• 既存の似たクラス1本（命名規約・層の分け方・例外の扱いが、説明より確実に伝わる）
• 関係するトリガやフローの有無（二重に更新が走る事故を防ぐ）
• 想定するデータ量（1件ずつか、一括か）

メタデータを集める作業そのものは、組織から取得すれば済みます。項目定義の一覧やメタデータの取り出しは、Salesforceワークベンチ(workbench)の機能一覧と使い方にまとめた方法で取れます。

③ テストクラスを一緒に書かせる

Salesforce は、本番へ反映するときにテストの網羅率を求められます。つまりテストクラスを書かずに済む選択肢がありません。それなら、実装と同時に書かせます。

このとき条件を2つ付けます。

• System.assert で結果を確かめること。 実行が通るだけのテストを書かないこと
• 一括処理（200件）の場合も通すこと

1つ目を書かないと、網羅率だけを満たす中身の無いテストが返ります。これはあとで不具合を見逃す原因になるだけでなく、テストがあるという誤った安心を作ります。

2つ目は Salesforce 固有です。1件で動いて200件で落ちるのは、繰り返しの中で検索や更新を呼んでいるときに起きます。テストを200件で通す決まりにしておくと、実装側も自然とまとめた形になります。

④ Org へ入れる前に、差分を見る

できたものを、そのまま組織へ反映しません。見るのは差分です。

• 変更されるファイルの一覧を先に出す（自分が頼んでいないファイルが入っていないか）
• 検証のみの反映（実際には適用しない形）で、テストを通す
• 反映先の組織を毎回確認する。接続先が複数あるとき、取り違えはいつでも起こりうる

最後の1つは手順というより決まりごとです。反映先の確認を省いた回だけ事故が起きます。 確認を人の注意力に任せず、反映の直前に接続先を表示させる形にしておくのが確実です。

任せてはいけないこと

共有・権限の最終判断

誰がどのレコードを見えるか、という設計は、AIに判断させません。影響範囲が組織全体で、しかも誤りの出方が「エラー」ではなく「見えてしまう」「見えない」という形になります。テストでも気づきにくく、気づくのは業務側から指摘されたときです。

案や比較表を作らせるのは有効です。決めるのは人です。

本番への反映

取り消せない操作は任せません。手順を書かせるのはよく、実行は人がやります。

Salesforce の場合、特に注意するのはデータの投入・更新です。コードの反映は戻せますが、上書きされたデータは戻りません。実行前にバックアップを取り、そのバックアップから実際に戻せることまで確かめます。ファイルができたことと、復元できることは別です。

ガバナ制限・API 制限の前提

「1回の処理で何件まで」「1日のAPI呼び出しが何回まで」といった前提は、組織の版と契約で変わります。AIは一般的な数字を書きますが、その組織の実際の上限とは一致しません。制限に関わる設計は、自分の組織の値を確認してから決めます。

うまくいかないときの原因

まとめ

Salesforce 開発でAIに任せる順番は、次のとおりです。

1. 設定で済むかを人が判定する（標準機能・宣言的機能・制限・確かめ方の4問）
2. メタデータを揃えて渡す（参照名・既存クラス1本・既存の自動処理・データ量）
3. テストクラスを一緒に書かせる（System.assert 必須・200件で通す）
4. 組織へ入れる前に差分を見る（変更ファイルの一覧・検証のみの反映・接続先の確認）

任せないのは、共有と権限の最終判断／本番への反映／制限の前提の3つです。

AIエディタを使った Salesforce 開発の全体像と用語はAIエディタを使ったVibe CordingでSalesforceの開発を行うに、実際の開発事例はAIエディタを使ったVibe codingの実際の開発事例にまとめています。コード生成そのものの様子はAI（ChatGPT）を使ったSalesforce開発（自動コード生成）が参考になります。

複数の作業を同時に走らせる段階に進むなら、複数の作業を同時に走らせるに事故の防ぎ方を含めてまとめています。

自分の組織の構成に合わせてこの流れを通したい方へは、AI開発トレーニングで1対1の形でお伝えしています。

Salesforce、Apex、SOQL、Lightning Web Components、AppExchange、Trailhead は、Salesforce, Inc. の米国およびその他の国における商標または登録商標です。その他、記載されている会社名・製品名は各社の商標または登録商標です。本記事は Salesforce, Inc. その他いかなる第三者からも、承認、提携、後援を受けたものではありません。

ところが試してみると、速くならない。許可を求めて止まったタブが並び、答えて回るのが仕事になる。完成したものが積み上がるのに、受け入れが追いつかない。しかも、気づかないうちに自分が作ったファイルが、別の作業の記録に紛れ込んでいる。

並行を詰まらせるのは、AIの速さではありません。起動方式の選び間違い、準備不足、そして人のレビューです。 この記事では、そこを順に潰す手順を書きます。実際に4本を並行させて起きた失敗も、そのまま載せます。

そもそも「同時に走らせる」とは

ここで言う「同時に走らせる」は、1つの大きな仕事を分けて、複数のAIに別々に進めさせることです。分け方は大きく3つあります。

①と②は別の仕組みではなく、同じサブエージェントの実行モードの違いです。別物だと思っていると、切り替えられることに気づけません。

選ぶ決め手は「途中で会話が必要か」

作業時間や規模で選ぼうとすると迷います。本当の分かれ目は、次の3つの問いです。

1. 設計判断が出てくる、仕様が固まっていないなど、途中で相談・方向修正が必要か
2. 今日で終わらない、中断して再開するなど、何日もかけて進めるか
3. 多くのファイルを書き換え、他の作業と同じファイルを触りうるか

どれか1つでも「はい」なら worktree ＋ 別セッション。 すべて「いいえ」ならサブエージェントで足ります。サブエージェントは1回の依頼で完結するので、方向がずれても最後まで走ってから気づくことになります。

迷ったらサブエージェントから始めてください。worktree は作業場の作成・統合・片づけの手間がかかります。「途中で相談したくなった」「今日で終わらない」と分かった時点で切り替えれば、途中まで進んだ内容は新しい作業場へ持っていけます。

選び間違えると、次のことが起きます。

いちばん多い失敗は、コマンドが要る作業を「裏で」動かすこと

裏で動かすサブエージェントは、許可を尋ねる相手がいないので、コマンドを実行できません。コマンドが要る作業を裏に回すと、着手する前に止まります。

対処は分業です。ファイルの編集だけをエージェントに任せ、コマンドの実行は自分（メインセッション）が行います。指示の末尾に次の一文を足します。

コマンドの実行はこちら（メインセッション）で行います。
あなたはファイルの作成・編集までを行い、完了報告に
「メインセッションで実行すべきコマンド」を列挙してください。

実装を並行させるなら、子セッションが要る

実装には git の操作やテストの実行が付きものです。裏で動かすエージェントだけでは完結しません。そのため実装を並行させるときは、メインセッションが子セッション（別タブの Claude Code）を起動し、会話し、統合する形をとります。「エージェントに全部やらせる」のではなく、「メインが子セッションを操る」。これが、いわゆる全自動の実体です。

このときメインは実装をしません。分解・作業場づくり・起動・連絡・統合・片づけに専念します。以降、このメインを管制塔と呼びます。人が手を動かすのは、最初の依頼と、止まったときの判断と、最後の受け入れだけです。

用意するもの

並行させる前に、次の4つがあるかを確かめます。無いまま始めると、右の列のことが起きます。

もう1つ、担当ファイルの一覧が要ります。誰がどのファイルを持つかを1つの表にして、全員が同じものを見られるようにします。

なぜ同じフォルダで並行できないのか。フォルダは「いま1つの状態」しか持てないからです。一方のセッションがブランチを切り替えると、フォルダの中身が丸ごと入れ替わり、もう一方が編集していた内容も一緒に消えます。worktree は、1つのリポジトリから作業フォルダだけを複数作る仕組みです。履歴は共有したまま、フォルダごとに別のブランチを開けます。

分けるかどうかの決め方は1つだけです。ファイルを1つでも書くなら作業場を分ける。読むだけなら分けなくてよい。「レビューするだけ」「調べるだけ」を理由に分けないのは危険です。調べた結果をまとめた文書も、立派な成果物だからです。実際に、「調査だけだから」と分けずに始めたセッションが数百行の調査メモを書き、それが別の作業の記録に紛れ込みました。そのコミットの題名は「デプロイ手順の訂正」で、中身には調査メモが丸ごと入っていました。内容が消えるわけではありませんが、題名と中身が一致しなくなり、あとから「あの変更だけを取り消したい」と思ってもできません。

手順

手順1　許可リストを整える

子セッションは、コマンドを実行するたびに許可を求めてきます。答えるまで、その子は止まったままです。よく使うコマンドを許可しておけば、この停止はほぼ無くなります。メインに次のように頼みます。

これから複数の作業を並行させます。
子セッションが毎回「実行してよいですか」で止まらないように、
許可リストを整えてください。

1. このプロジェクトでよく使うコマンドを洗い出す
   （テスト実行 / ビルド / 状態確認 / 差分確認 など）
2. そのうち「読み取りだけ」「元に戻せる」ものを許可リストの候補として挙げる
3. 候補を一覧で見せてから、私が承認したら設定に追加する

次のものは許可リストに入れないでください。
- ファイルやフォルダを消すもの
- 外部へ送信するもの（デプロイ・アップロード・メール送信）
- 本番環境に触れるもの
追加した内容は、あとで見返せるように記録も残してください。

なぜ最初にやるのか。 ここを先に潰しておくと、走らせている間にやることが本当に減るからです。許可リストに入れるのは「読み取りだけ」「元に戻せる」ものに限ります。消す、送る、本番に触れる、は入れません。

禁止リストも、準備としては同じ時点で入れます。独立した節で詳しく書くので、先に手順の続きを進めます。

手順2　CLAUDE.md に並行のルールを書く

並行のルールを CLAUDE.md に貼っておくと、毎回同じことを指示せずに済みます。入れる項目は次のとおりです。

## 並行開発のルール

### 所有権を先に決める
- 作業を割る前に「どのファイルを誰が触るか」の表を作り、全員が同じ表を見る
- 表は tasks/ownership.md に置き、変更は管制塔だけが行う
- 所有権は「ファイル」ではなく「そのデータへの書き込みロジック」で切る

### 触ってよい範囲
- 自分の作業場から出ない。他の担当のファイルは読んでよいが、書いてはいけない
- 必要になったら、自分で直さず「こう変えたい」と管制塔へ報告する
- 共有ファイル（設定・共通関数・型定義）は管制塔が持つ

### 報告のしかた
- 区切りごとにコミットする（作業が失われるのを防ぐ／進捗が外から見える）
- 検証が終わっていないものを「終わった」と書かない

### 止まる条件（必ず人に聞くこと）
- 担当ファイルが重なるとき
- 統合で競合が出たとき
- 仕様の解釈が2通り以上あるとき
- 消す・上書きするなど、元に戻せない操作をするとき

なぜか。 「所有権をファイルではなく書き込みロジックで切る」のは、ファイル単位で分けたつもりでも、同じデータを2か所から更新する構造ができてしまうことがあるからです。そうなると、どちらを正とするかを後から決め直すことになります。

手順3　セッションどうしが連絡できるかを確かめる

管制塔から子セッションへ直接メッセージを送れる環境かどうかを、先に確認します。送れない場合は、あなたが内容を転記することになり、進め方が変わります。次の1行で足ります。

いま起動している Claude Code のセッションを一覧で出せますか。
出せる場合、そのセッションへ直接メッセージを送れるかも教えてください。
できない場合は、その旨だけ答えてください。

手順4　プロンプト1本で回す

準備ができたら、依頼は1回で済みます。分解・作業場づくり・起動・指示・進捗管理・統合・片づけまで、1本に含めます。要点は次の5つです。

1. 分解　1つ1〜3時間で終わる粒度に割る。担当ファイルが重ならないよう割り当て、一覧を tasks/ownership.md に残す。分解結果は画面に出させるが、承認は待たせない
2. 作業場づくりと起動　作業ごとに worktree を作り、Git 管理外だが必要な設定ファイルを引き継ぎ、子セッションを起動して最初の指示を渡す
3. 走っている間　完了したら通知を受ける形にし、子どうしを直接やり取りさせない。指示が誤っていたら、気づいた1本だけでなく全部の作業場へ訂正を配る
4. 完了報告を受けたら　鵜呑みにせず、履歴と差分を自分で確認してから受け入れる
5. 統合と片づけ　小さいものから順に統合し、1本統合するごとに残りへ最新を取り込む。最後に統合後の状態で動作確認まで行う

子セッションに渡す最初の指示には、必ず次を含めます。何をするか（前提を知らない相手に説明する形で）、触ってよいファイルと触ってはいけないファイル、完了条件、コミットまで行い push はしないこと、完了したら何を報告するか。

そして、次の場合は必ず止まって人に聞かせます。

• 担当ファイルが重なってしまう
• 統合で競合が出た
• 仕様の解釈が2通り以上ある
• 消す・上書きするなど、元に戻せない操作をする

これ以外は自分の判断で進めさせ、決めたことは理由とセットで1か所に記録させます。「私の承認は待たなくてよい」を入れるのは、分解のたびに止めると自動化した意味がほぼ無くなるからです。 ただし、分解の結果を画面に出させることだけは残してください。止まらないので手間はゼロですが、あとで問題が起きたときに「どう割り当てたか」を遡れます。これが無いと、原因を追うところからやり直しです。

並行が2〜3本で、領域が明確に分かれ、新規ファイルの追加が中心なら、分解の承認は省略して構いません。逆に、並行が4本以上、同じモジュールを複数が触る、共通部分（設定・共通関数・型定義）に手が入る、といった場面では止めてください。省略するなら、統合の前に作業場どうしの重なりを検出させることで補います。事前に止めるか事後に見つけるかの違いで、どちらも無いと、競合に気づくのがマージの瞬間になります。両方の作業が終わってからのやり直しです。

手順5　受け入れて、統合して、片づける

人がやるのは受け入れの判断です。読む前に、メインに照合させます。

並行して進めた作業を受け入れます。私が読む前に、次を確認して一覧で報告してください。
1. 各作業が完了条件を満たしているか（1つずつ照合して結果を書く）
2. 割り当てたファイル以外を触っていないか（差分で確認する）
3. 作業場どうしで同じファイルを触っていないか
4. 同じ用途のものを別々に作ってしまっていないか
5. 顧客名・パスワードの混入が無いか（機械的に検査する）
6. 私が判断すべき点（作業ごとに3点以内）
「問題ありません」だけの報告はしないでください。
確認した内容を1項目ずつ示してください。

レビューは「読む」のではなく「完了条件に照らす」作業にします。そうしないと、読むたびに気になる点が増えて終わりません。機密の混入は目視ではなく検索で確認します。直すときは全部やり直しではなく、どこを・なぜ・どう直すかを指定します。

統合は、変更量が小さいものから順に行います。大きい方を先に入れると、小さい方が大量の競合を抱えるからです。1本統合したら、他の作業場へ最新を取り込みます。ずれが小さいうちに解消するためです。競合が出たら、管制塔のフォルダで直します。子セッションに直させると、同じ箇所を別々に直して、さらに壊れます。統合し終えたら作業場と枝を消します。残すと、次に間違えてそこで作業してしまうからです。

人が手放してはいけないのは3つです。レビューと受け入れ、競合の解消方針、仕様の解釈が割れたときの決定。 どれもやり直しが効かない判断です。

事故を防ぐ設定 — 許可リストとセットで「禁止リスト」も入れる

許可リストは「止まらないようにする」ためのものでした。これとは別に、並行させるなら必ず入れておきたい禁止があります。「変更を全部まとめて記録する」操作です。

禁止リストの対象は、git add -A、git add .、git add --all、git commit -a です。書き方の違いで抜けないよう、表記ゆれもまとめて並べます。1つでも漏れると、そこから入ってきます。

設定ファイルの書き方は使っているツールによって違うので、自分で書式を調べるより、後述のようにメインへ頼んで入れてもらうのが確実です。

もう1つ入れるのが、記録する直前に、いま自分がどのブランチに居るかを毎回表示させる仕組みです。セッションを始めたときの表示は、途中で古くなります。別のセッションがブランチを切り替えると、自分が変えていないのに、居る場所が変わります。「記録したはずの変更が、目的のブランチに無い」という事故は、これで起きます。

メインには、次のように頼みます。

複数のセッションを並行させるので、事故防止の設定を入れてください。

1. 「変更を全部まとめて記録する」操作を禁止リストに入れる
   （git add -A / git add . / git add --all / git commit -a）
   → 記録は必ずファイル名を指定する形にしたい
2. 記録する直前に、いま自分がどのブランチに居るかを
   毎回表示するようにしてください
   → セッションを始めたときの表示は、途中で古くなるため
3. 入れ終わったら、実際に禁止されているかを1回試して確認してください
   （危険のない形で試せる方法があれば、それで確認してください）

設定した内容と、確認した結果を報告してください。

3番を必ず入れてください。設定に書いただけでは、確認になっていません。

なぜ「ルールを書く」ではなく「設定で止める」のか

同じ事故を防ぐために、CLAUDE.md に禁止事項として書いた対策が、2回とも破られたことがあります。2回目は、そのルールを書いた本人（AI）が、ルールを読める状態のまま破りました。

「なぜそうするか」は CLAUDE.md に、「何を禁止するか」は設定に書く。文章で書いたルールは実行直前に読まれる保証がない。

CLAUDE.md は、AIが判断するときの理由と背景を伝える場所です。ただ、実行の直前に読み返される保証はありません。実行を止められるのは設定だけです。この2つを混ぜると、片方が効かなくなります。禁止を文章だけで書いて満足しないでください。

なお、禁止リストは最後の網です。そもそも作業場を分けていれば、他のセッションのファイルを巻き込む事故は起きません。分ける、禁止する、直前に現在地を見る、の3つを重ねておくと、どれか1つが抜けても事故になりません。

走っている間に見る場所

並行しているものを全部追いかける必要はありません。見る場所は5つに絞れます。このうち1と3だけが、人にしかできません。

状況は、1日1〜2回、次のようにまとめて出してもらいます。

いまの状況をまとめて出してください。
1. 各作業場の進み具合（コミット数 / まだ保存していない変更の数 / 直近の作業内容）
2. 全体の到達点
3. 作業場の一覧（放置されているものがあれば指摘する）
4. 使っている資源の残り（外部サービスの呼び出し回数・容量など）
5. 私の確認待ちになっているもの
6. 止まっているもの（あれば理由も）
確認待ちが3件を超えていたら、新しい投入を止めて
先に見るべきものから順に出してください。

「まだ保存していない変更の数」を入れているのは、子セッションが長時間コミットせずに書き続けていることがあるからです。そのまま落ちると全部失われます。「区切りでコミットして」と伝えるだけで防げます。

並行数の目安

並行数を増やせば速くなる、というのは途中までしか正しくありません。レビューするのは常に自分1人なので、そこが詰まると全体が止まります。増やすべきは投入数ではなく、片づける速さです。 レビュー待ちが増えたら、新しい投入を止めて片づけを優先してください。

並行してよいかの判定は、「Aが終わっていなくてもBを始められるか？」と問うだけです。始められないなら順番が必要です（データ構造の変更から実装へ、公開から動作確認へ、同じファイルを2人が編集、など）。

4本以上を回すときに効いたこと

2〜3本と4本以上では、必要な仕組みが変わります。実際に4本を並行させて分かったことです。

報告と実物がずれた実例

実際に4本を回したとき、次のずれが起きました。悪意はなく、自分の手元しか見えていないことが原因です。

• 「コミット8本」と報告されたが、実際は10本だった
• 「この不具合を直してほしい」と2回報告されたが、すでに直っていた（その担当の手元が古いままだった）
• 管制塔が「この変更で直るはず」と見立てたが、前提を1つ見落としていて外れた

報告を受けたら、履歴と差分を自分で確認してから受け入れる。これが管制塔の中心的な仕事になります。

並行数は「レビュー能力」だけでは決まらない

3〜4本という目安は、レビューが詰まる限界から来ています。実際にはもう1つ、環境側の上限があります。外部サービスの1日あたり呼び出し回数、テスト環境の容量、ビルドの同時実行数などです。4本が同時に検証を回すと、1本のときの4倍の速さで上限に達します。実例として、開発用の検証環境が1日の呼び出し上限に達し、4本すべてが半日止まりました。 並行を増やす前に、共有している資源の上限を1度確認してください。

うまくいかないときの原因

並行運用で起きる失敗に絞って整理します。

最初の1週間の進め方

いきなり並行させないことです。1件を最後まで通す経験がないと、詰まったときに原因が分かりません。

並行は3日目以降、スキル化は7日目でよい、という目安です。

チェックリスト

並行させるとき

• このセッションはファイルを書くか。書くなら作業場を分けたか（「調べるだけ」でも成果物は生まれる）
• 「変更を全部まとめて記録する」操作を禁止リストに入れたか
• その禁止が実際に効くかを1回試して確かめたか（設定に書いただけでは確認になっていない）
• 元のフォルダは管制塔専用にして、そこで作業していないか
• レビュー待ちは3件以下か

レビューのとき

• 完了条件を1つずつ照合したか
• 機密の混入を検索で確認したか
• 直すなら、どこを・なぜ・どう直すかを指定したか
• かかった時間を記録したか

補足　自分でコマンドを打って並行させる

ここまでの自動化は、メインセッションが次の手順を代わりに実行しているだけです。うまく動かないときに中身を確かめられるよう、手動の手順を残します。

# 1. 作業場を作る（main から feature-a という枝を切って、隣に新しいフォルダを作る）
git worktree add ../myproject-feature-a -b feature-a

# 2. その作業場へ移動して、子セッションを起動する
cd ../myproject-feature-a
claude

# 3. 統合する（管制塔のフォルダに戻ってから）
cd ../myproject
git merge feature-a

# 4. 片づける（統合が終わったら作業場と枝を消す）
git worktree remove ../myproject-feature-a
git branch -d feature-a

注意したいのは、競合を防ぐのは worktree ではなく「割り当て」だということです。worktree はフォルダを分けるだけで、統合するときの競合は防ぎません。2つの作業場が同じファイルの同じ行を直していれば、マージで必ずぶつかります。子セッションの最初の指示には、触ってよいファイルと触ってはいけないファイルを明示してください。

この作業場（feature-contact-form）で、問い合わせフォームを実装してください。

【触ってよいファイル】
- src/forms/contact.py（新規作成）
- src/forms/__init__.py（1行の追記のみ）
- tests/test_contact.py（新規作成）

【触ってはいけないファイル】
- src/main.py     … 別の作業場が触っています
- config.json     … 管制塔が管理しています
必要になった場合は、自分で編集せず「こう変えたい」と報告してください。

【完了条件】
- テストが通ること
- 上記3ファイル以外に変更が無いこと（git status で確認する）

【完了したら】
1. コミットまで行う（push はしない）
2. 変更したファイルの一覧を報告する
3. 私（管制塔）に伝えるべき点があれば書く

子セッションどうしは会話させません。情報は必ず管制塔を経由させます。直接やり取りさせると、何が決まったのかを管制塔が把握できなくなります。

まとめ

• 同時に走らせる前に、起動方式を選ぶ。決め手は「途中で会話が必要か」。迷ったらサブエージェントから始める
• 実装を並行させるなら、worktree で作業場を分け、ファイルを1つでも書くなら分ける
• 準備は3つ。許可リストを整え、禁止リストで「全部まとめて記録」を止め、並行のルールを CLAUDE.md に書く
• 「なぜ」は CLAUDE.md に、「何を禁止するか」は設定に書く。文章のルールだけでは止まらない
• 速くなるかどうかは、投入数ではなく片づける速さで決まる。レビュー待ち3件で投入を止める
• 報告は鵜呑みにしない。履歴と差分を自分で確かめる

最初から4本を回す必要はありません。1件を最後まで通し、次に2件を並行させ、禁止リストが実際に効くことを1回試す。ここまで通せば、並行運用の土台はできています。

この記事の進め方を、自分のプロジェクトに合わせて組み立てたい場合は、1on1のトレーニングで一緒に設定しながら進めることもできます。作業場の分け方や禁止リストの入れ方は、実際のリポジトリを見ながらのほうが早く決まります。

内容を知りたい方はAI開発トレーニングのページをご覧ください。

あるいは、試しに「議事録をまとめておいて」と頼んでみたものの、返ってきたものを読み直すうちに「これなら自分でやったほうが早い」と感じた。

どちらも、ツールの使い方ではなく、最初の1件の選び方と頼み方でつまずいています。この記事では、画面の見方から、最初の1件を最後まで通すところまでを、順に説明します。

そもそも「AIに開発を任せる」とは

ここでいう「任せる」は、質問して答えをもらうこととは違います。作業そのものを頼むことです。

たとえば「打合せの書き起こしを議事録に整えて、決まった場所にファイルとして保存して」と頼む。AIは書き起こしを読み、文書を作り、ファイルとして置くところまで進めます。あなたは、できあがったものを確認して受け取ります。

この記事で使うのは Claude Code というツールです。ターミナル（文字を打って操作する黒い画面）の中で動きます。名前は難しく見えますが、覚える登場人物は4つだけです。これを取り違えると「なぜ動かないのか」が分からなくなります。

最初のうちは、「話し相手がいて、毎回読まれるルール帳（CLAUDE.md）と、必要なときだけ開く手順書（スキル）がある」と捉えれば十分です。サブエージェントは、最初の1件では使わなくても構いません。

用意するもの

始める前に、次の3つを手元に置いてください。「無いとどうなるか」も書いておきます。

なお、Claude Code のインストールは済んでいる前提で進めます。

手順

ステップ1　作業フォルダで起動し、画面の見方をつかむ

作業したいフォルダへ移動して claude と打つと始まります。

cd C:Users自分の名前Documentsmyproject
claude

なぜそうするか　AIは、起動したフォルダの中を作業場として扱います。どのフォルダで始めるかが、そのまま作業範囲になります。

画面は、上から順に「入力 → 作業ログ → 返答 → 次の入力」と流れていきます。覚える操作は、まず次の6つだけです。

最初のうち、いちばん役に立つのは Esc キーです。「違う方向に進んでいる」と感じたら、最後まで待たずに止めてください。途中で止めても壊れません。そのまま「いまのは違います。◯◯してください」と伝えれば軌道修正できます。

あわせて、次のコマンドを知っておくと安心です。

ステップ2　ファイル変更の確認は、慣れるまで毎回「はい」で見る

AIがファイルを書き換えたりコマンドを実行したりするとき、実行してよいかを確認してきます。内容を見て、許可するかを選びます。

なぜそうするか　「今後は確認しない」を選ぶと速くなりますが、何をされたか把握できなくなります。最初の1週間は都度確認して、AIが何をしているかを見ておくことをおすすめします。

なお、確認の文言や選択肢はバージョンによって変わります。選び方の考え方だけ押さえてください。

ステップ3　CLAUDE.md を置く

CLAUDE.md は、作業フォルダの直下に置くテキストファイルです。毎回のセッションで自動的に読み込まれます。「毎回同じ説明をしている」と感じたら、それは CLAUDE.md に書くべき内容です。

最初は、次の最小構成をコピーして、作業フォルダに CLAUDE.md という名前で保存してください。

# プロジェクトのルール

## このプロジェクトについて
- 目的: （何を作っているか / 何のための作業場か を1〜2行）
- 使う技術: （例: Python / Excel 生成 / WordPress など）

## 作業の進め方
- 日本語で回答する
- コードのコメントも日本語で書く
- 大きな作業は、着手前に手順を提示して確認を取る
- ファイルを編集する前に、必ず現状を確認する
- 勝手にファイルを削除しない

## 出力のルール
- 作成・更新したファイルは、必ず絶対パス（フルパス）で示す
- 成果物は次の場所に置く
  - 計画・手順書 -> plans/
  - 資料・ドキュメント -> docs/
  - 作業メモ -> tasks/

## 禁止事項
- パスワード・APIキー・顧客名を、共有するファイルに書かない
- 確認なしに外部へ送信しない（メール・API・アップロード）

「目的」と「使う技術」の2行だけ、自分の言葉に書き換えれば使えます。

なぜそうするか　AIは会話が変わると、前の指示を覚えていません。毎回読ませたいルールをファイルにしておけば、同じ説明を繰り返さずに済みます。

書くべきかの見分け方は、「2回以上、同じ指示をしたものは書く」です。逆に、その日限りの指示は書かないでください。ファイルが膨らむと、読まれる密度が下がります。

置き場所は3段階あり、下の階層ほど優先されます。

最初は、真ん中の「作業フォルダ直下」だけで十分です。

ステップ4　スキルは、2〜3回やってから作る

スキルは、特定の作業手順をまとめたファイルです。毎回ゼロから指示を書くと、指示を書く時間そのものが負担になります。繰り返す作業はスキルにしておくと、手順と書式が固定され、出来のばらつきが消えます。

ただし、最初の1件では作りません。

なぜそうするか　はじめから完璧なスキルを作ろうとすると、使わないものができます。2〜3回同じ作業をやって手順が固まってから、ファイルにしてください。そのとき「前回の指示をそのまま貼る」だけで、ほぼ完成します。

作るときも、自分で書く必要はありません。AIに作ってもらうのがいちばん早い方法です。たとえば、次のように頼みます。

いま行った作業を、次回から使い回せるようにスキルにしてください。

対象の作業: （例）打合せの書き起こしから議事録を作る作業

作ってほしいもの:
- スキルのファイル（SKILL.md）を作る
- 先頭の description には、私が実際に打ちそうな言い回しを入れる
  （例:「議事録を作って」「打合せメモをまとめて」）
- 手順・守ること・完了報告の形を書く
- 今回の作業で私が指摘した点は、すべて「守ること」に反映する

作る前に、内容の要点を箇条書きで見せてください。
私が確認してからファイルにしてください。

スキルは C:Users自分の名前.claudeskills名前SKILL.md に置きます。先頭の description（いつ使うかの説明）が曖昧だと、作っても呼ばれません。「議事録を作って」のように、自分が実際に打ちそうな言い回しを入れておくのがコツです。

名前の末尾で種類が分かるようにしておくと、後で整理しやすくなります（スキルは -skill、エージェントは -agent）。数が増えてから直すのは手間なので、1つ目を作るときから付けてください。

ステップ5　最初の1件を、5つの要素をそろえて頼む

いきなり並行させないでください。1件を最後まで通すのが最短です。

今日やる予定の作業から1件だけ選び、次のテンプレートに当てはめて投げます。

次の作業を任せてください。

【目的】
9月10日の打合せ議事録を、社内共有できる形に整える

【入力】
docs/meeting/2026-09-10-raw.txt（音声書き起こしの生データ）

【成果物】
docs/meeting/2026-09-10.md を1つ作る
 - 見出し構成: 決定事項 / 宿題（担当・期限つき） / 議論の要点 / 次回予定
 - 決定事項は箇条書きで、1項目1行

【制約】
- 発言者の個人名は「営業担当」「開発担当」のように役割名へ置き換える
- 推測で内容を補わない。不明な箇所は「（聞き取り不明）」と書く

【完了条件】
- 上のファイルが作成されている
- 宿題がすべて「担当」と「期限」を持っている

【完了報告に書くこと】
- 作成したファイルの絶対パス
- 判断に迷った箇所（あれば）
- 私が確認すべき点

なぜそうするか　5つの要素は、どれも「書かないと後で自分が困る」ものです。

返ってきたら、完了条件に照らして確認します。レビューに何分かかったかを計っておくと、次から見積もれるようになります。

任せてはいけないこと（最初の1件に限って）

何を任せ、何を任せないかの全体像は、AIに何を任せ、何を任せないかで詳しく扱います。ここでは、最初の1件で避けたいことに絞ります。

1. 「議事録をまとめておいて」だけで頼まない。 返ってきたものを読み直すところから始まり、レビューが「自分でやり直す」のと変わらなくなります。ステップ5の5つの要素をそろえてください。
2. 最初から複数件を同時に走らせない。 まず1件を最後まで通して、頼み方とレビューの重さをつかんでからにします。
3. 顧客・社外へのやり取りや、成果物の最終的な受け入れ判断は任せない。 下書きまではAIに任せても、送る・受け入れるの判断は自分で行います。

うまくいかないときの原因

まとめ

最初の1件を任せるまでに、やることは4つです。

1. 作業フォルダで claude を起動し、Esc で止められることを知っておく
2. 最初の1週間は、ファイル変更の確認を都度見る
3. 毎回の説明を、CLAUDE.md に書く
4. 目的・入力・成果物・制約・完了条件・報告の形をそろえて、1件だけ頼む

スキルやエージェントは、同じ作業を2〜3回やってからで間に合います。先に仕組みを作り込むより、1件を通してレビューにかかる時間を知るほうが、次の一歩が見えます。

自分の仕事に当てはめて進めたいときは、1on1で伴走するAI開発トレーニングもあります。どの作業から任せるか、頼み方をどう型にするかを、実際の題材で一緒に整理します。

内容を知りたい方はAI開発トレーニングのページをご覧ください。

線を引けないのは、判断の軸が「難しいかどうか」になっているからです。軸を変えると、迷いはかなり減ります。この記事では、AIに任せる仕事の範囲を決める基準と、任せてはいけない仕事を整理します。

そもそも「AIに仕事を任せる」とは

ここで言う「任せる」は、質問して答えをもらうことではありません。目的と完了条件を伝え、調査・下書き・実装・テストといった一連の作業をAIに進めてもらい、返ってきた結果を人が受け取ることです。

質問と違い、任せた仕事は人の見ていないところで進みます。だからこそ、何を渡すかより先に何を渡さないかを決めておく必要があります。

判断の境界は「難しさ」ではありません。間違えたときに、やり直しが効くかどうかです。難しい実装は任せてかまいません。間違えてもテストで気づき、直せるからです。一方、簡単でも顧客へのメールは任せません。送ってしまえば取り消せないからです。

用意するもの（入力）

任せる前に、次の4つを手元に揃えます。無いまま任せると、右の列のことが起きます。

指示には、目的・成果物・制約・完了条件・報告形式の5つを書くと抜けが出ません。特に確かめ方は、後述の「任せてはいけない仕事」の線引きに直結します。

手順

判断は3つの問いに答えるだけです。上から順に当てはめます。

ステップ1　間違えたとき、やり直しが効くか確認する なぜ最初に問うか：取り消せないものは、後からの確認では間に合わないからです。送信済みのメール、顧客への発言、承認は取り消せません。「いいえ」なら自分でやります。

ステップ2　返ってきた結果を、自分で確かめられるか確認する なぜ次に問うか：確かめられない結果は、受け取った時点で品質が分からないからです。読めば分かる、テストが通れば分かる、のどちらかが成り立つなら任せられます。成り立たないなら、先に確かめ方（受け入れ基準・テスト・見本）を作ります。それができるまでは任せません。

ステップ3　コマンド実行が必要かで、動かし方を決める なぜ最後に問うか：任せるかどうかではなく、任せ方の問題だからです。gitやテスト実行、インストールなどコマンドの実行が必要な作業は、待ちながら動かします（前景）。実行が要らない調査や下書きは、裏で動かします（バックグラウンド）。

ステップ4　複数を同時に任せるなら、順番が必要な仕事を見分ける なぜ確認するか：同時に走らせても、前の結果を待つ仕事は速くならず、衝突するからです。判定は「Aが終わっていなくてもBを始められるか」と問うだけです。始められないなら、順番が必要です。

並行して走らせるときの設定や事故の防ぎ方は、複数を同時に走らせる方法で扱います。

任せてよい仕事の典型は次のとおりです。

• 調査・比較検討
• 文書やコードの下書き
• 実装・修正
• テスト作成
• 形式変換・一括置換
• 図表・スライドの生成
• 既存コードから仕様書を起こす

任せてはいけないこと

ここがこの記事の中心です。任せてはいけない仕事は、突き詰めると3つに絞れます。

1. 取り消せないことの実行

顧客・上長とのやり取り、見積の対外提示、契約・料金に関わる判断。

これらは「下書きまで」は任せられますが、出す行為と、出してよいという判断は人が持ちます。AIの文章が整っているほど、確認せずに出したくなる誘惑が強くなる点に注意が必要です。簡単な仕事に見えても、ステップ1で「いいえ」になります。

2. 受け入れ・優先順位・最終決定

成果物を受け入れるかどうか、何を先にやるか、設計をどう決めるか。

AIは材料と選択肢を出せますが、何を優先し、どれで行くかは、結果の責任を負う人が決めることです。ここを任せると、仕事は進んでいるのに、誰も決めていないまま積み上がります。受け入れの判断を飛ばして次を投入し続けると、レビュー待ちが詰まり、成果物は増えるのに完了しない状態になります。

3. 確かめ方がない仕事

読んでも判断できず、テストも見本もない仕事。

難しさや重要度とは関係なく、確かめられない仕事は任せられない仕事として扱います。任せるなら、先に受け入れ基準・テスト・見本のどれかを用意します。用意できたなら、その仕事は「条件つきで任せられる」に変わります。

うまくいかないときの原因

任せてうまくいかないときの多くは、AIの能力ではなく、渡し方か線の引き方に原因があります。

まとめ

• 判断の軸は難しさではなく、間違えたときにやり直しが効くか
• 任せる前に、自分で確かめられるかを確認する。確かめ方が無ければ、先に作る
• 任せてはいけないのは、取り消せないことの実行／受け入れ・優先順位・最終決定／確かめ方がない仕事の3つ
• うまくいかないときは、能力ではなく渡し方と線の引き方を見直す

線の引き方は、実際に1件任せて、返ってきたものを受け取ってみると体感でつかめます。自分の仕事のどこに線を引くか、どの確かめ方を先に用意するかは、仕事の中身によって変わります。1on1のAI開発トレーニングでは、あなたの実際の業務を題材に、この線引きを一緒に整理しています。

内容を知りたい方はAI開発トレーニングのページをご覧ください。

しかも呼び方が現場ごとに違います。同じものを画面設計書と呼ぶ会社もあれば、画面定義書、画面仕様書と呼ぶ会社もある。前の現場の言葉が通じません。

この記事では、設計工程で作る成果物を種類別に並べ、それぞれのExcelテンプレートへの入口をまとめました。どれから手をつけるかの順序もあわせて示します。

設計工程の成果物は「一覧」と「設計書」の2階建てになっている

最初に、全体の構造を押さえておきます。設計工程の成果物は、ほぼ例外なく2階建てです。

一覧で「いくつあるか」を確定させ、設計書で「中身をどうするか」を決めます。

この順序を逆にすると破綻します。画面定義書を先に書き始めると、書いている途中で「この画面、隣のチームが作っている画面と同じでは」という話が出ます。画面IDが採番されていないので、どちらを残すかの判断もできません。手戻りは設計書1冊まるごとになります。

一覧が先である理由はもう1つあります。見積もりと進捗管理が一覧の行数を単位にしているからです。画面が38本あると分かって初めて、工数も進捗率も出せます。設計書から書き始めると、終わりが見えないまま進むことになります。

設計書・定義書・仕様書は、ほぼ同じものを指している

呼称の違いは、内容の違いではありません。会社と時代の違いです。

厳密に使い分けている現場もありますが、多くの現場では同じものを違う名前で呼んでいるだけです。テンプレートを探すときは、3つとも試してください。

工程の呼び方も同じです。

ただし実務では、1つのExcelブックの中に基本設計と詳細設計の両方が入っていることがよくあります。処理概要のシートは基本設計、入出力処理設計のシートは詳細設計、というように混在します。工程で分冊しようとすると、かえって管理が煩雑になります。

画面まわりの設計書

利用者が直接触る部分です。設計工程で最も分量が多くなります。

• 画面一覧 — 画面IDを採番し、画面の数を確定させます。すべての起点になります
• 画面定義書／画面設計書 — 1画面ずつ、レイアウト・画面項目定義・表示条件・入力チェック・入出力処理設計まで書きます
• 画面遷移図 — 画面同士のつながり。単体では正しく見えても、つないだ瞬間に破綻する経路が見つかります
• メッセージ設計書 — メッセージIDの設定ルールと文言。画面定義書の入力チェックと対になります
• 選択リスト定義書 — 選択肢の一覧と値。画面と帳票の両方から参照されます

メッセージ設計書は後回しにされがちですが、分散させると同じ意味の文言が画面ごとに違うという状態になります。1か所に集めておく価値があります。

帳票まわりの設計書

• 帳票一覧 — 帳票の数と出力方式を確定させます
• 帳票設計書／帳票定義書 — 出力項目・レイアウト・出力件数と性能まで

帳票で問題になるのは、たいてい件数です。レイアウトの議論は進むのに、月末に何万件出るのかが最後まで決まらない。性能問題は本番直前に出ます。一覧の段階で件数の欄を埋めておくと、後半が楽になります。

データモデルまわりの設計書

• データモデル・オブジェクト設計 — 概念データモデルから設計に落とす進め方。オブジェクト定義書のテンプレートもここから辿れます
• CRUD図／CRUDマトリクス表 — 機能とデータの関係。どの機能がどのデータを作り、更新し、消すか
• コード設計書／コード定義書 — コード体系と値の定義。区分値をどこで持つか

CRUD図は省略されることが多い成果物です。ただし**「このデータは誰が作るのか」が誰も答えられない**状態に気づけるのは、この表だけです。作るなら機能×オブジェクトのレベルまでで十分で、項目レベルまで作ると維持できなくなります。

処理・バッチまわりの設計書

• プログラム一覧 — 実装対象の数。機能種別ごとの難易度と規模を定義しておくと見積もりに使えます
• バッチ処理一覧 — バッチの数と処理方式
• バッチ処理設計書 — 処理概要・処理フロー図・入出力処理設計
• ジョブスケジュール — 起動サーバ・サイクル・時刻。バッチ同士の順序と依存
• トリガー処理設計書 ／ トリガー一覧 — データ更新をきっかけに動く処理

ジョブスケジュールは一覧の一種ですが、時間軸で見ないと衝突が見つかりません。処理単体では正しくても、同じ時刻に重い処理が3本走る設計になっていることがあります。

外部連携まわりの設計書

• 外部インタフェース一覧／連携全体図 — 連携の数と方向。全体図があると相手先との合意が早くなります
• 外部インタフェース設計書 — 処理概要・連携処理フロー・データ移送項目

外部連携は相手がいるため、自分たちだけでは決められません。設計工程の中で最初に着手すべき領域です。

どこから手をつけるか

順序をまとめると、こうなります。

1. システム機能一覧 で、作るものの全体像を確定させる
2. 各種の一覧（画面・帳票・バッチ・外部連携・プログラム）で、数と粒度を決める
3. 外部連携の設計書から着手する（相手との調整に時間がかかるため）
4. 画面・帳票の設計書を進める
5. 処理・バッチの設計書とデータモデルを固める

一覧がすべて揃った時点で、設計工程の残作業が行数で見えるようになります。ここが引けているかどうかで、後半の進め方が変わります。

テンプレートを埋める作業をどう減らすか

テンプレートを配っても、埋める作業は残ります。設計工程で時間を食うのは様式を整えることではなく、項目を1つずつ書いていく作業です。

この部分は生成AIにかなりの割合を任せられます。ただし任せられる範囲と、任せてはいけない範囲が分かれます。具体的な手順は別の記事にまとめました。

• 画面定義書をAIに書かせる手順
• 機能一覧をAIに作らせる手順

まとめ

• 設計工程の成果物は**「一覧」と「設計書」の2階建て**。一覧で数と粒度を決め、設計書で中身を決める
• 順序を逆にすると手戻りが設計書1冊単位になる。見積もりと進捗も一覧の行数が単位
• 設計書・定義書・仕様書はほぼ同じもの。基本設計＝外部設計、詳細設計＝内部設計
• 1つのExcelブックに基本設計と詳細設計が混在するのは普通。工程で分冊しなくてよい
• 着手順は機能一覧 → 各一覧 → 外部連携 → 画面・帳票 → 処理・データモデル

テンプレートの埋め方や、プロジェクトに合わせた様式の調整を手を動かしながら身につけたい方は、AI開発トレーニングで個別にお伝えしています。

品質会議で「今週は15件でした」と報告して終わる。傾向を聞かれても答えられない。テストの終盤になって、同じような不具合が繰り返し出ていたことに気づく——。

原因は、記録していないことではありません。溜めた記録を分析する工程が、誰の仕事にもなっていないことです。この工程は手間がかかるわりに、やらなくても表面上は困りません。だから真っ先に省かれます。

ここは生成AIで大きく変わる領域です。分類と傾向出しはAIに任せ、人は打ち手を決めることに集中できます。

分析や分類をどこまで任せ、どこから自分で判断するかの基準はAIに何を任せ、何を任せないかでまとめています。

なぜ原因分類は形骸化するのか

形骸化には、はっきりした理由が3つあります。

1. 分類を決めるのが早すぎる プロジェクト開始時に「こんな分類が必要だろう」と机上で決めます。実際に障害が出始めると当てはまらず、判断に迷ったものが全部「その他」に流れます。気づくと半分が「その他」になっています。

2. 登録する人によって基準が違う 同じ「画面に想定外の値が出る」でも、ある人は「表示不具合」、別の人は「計算誤り」と入れます。集計しても実態を表さないので、誰も見なくなります。

3. 分析する時間が確保されていない 分類はされていても、集計して傾向を読む人がいません。テスト工程は常に逼迫しているため、この作業は必ず後回しになります。

AIで解けるのは主に1と2です。3は、1と2の手間が減った結果として時間が生まれます。

用意するもの

重要なのは、事象と原因が文章で書かれていることです。分類コードだけが入っていて記述が空欄の表は、AIに渡しても何も出てきません。逆に、記述さえあれば分類が雑でも整理できます。

手順

① 分類の定義を、実際の障害から作り直す

机上で決めた分類を捨て、実際に起きた障害から帰納して作り直します。

溜まった障害の事象と原因の記述をまとめて渡し、「この障害群を、原因の性質で5〜8種類に分類する定義を作って」と依頼します。件数が偏らないように、と添えると実用的な粒度になります。

出てきた定義を人が確認し、現場の言葉に直します。AIは一般的な用語を使いたがりますが、分類はチーム内で通じることが最優先です。

このとき、障害管理表の設計そのもので解説しているとおり、障害分類（起きた事象の種別）と根本原因（なぜ作り込まれたか）は別の列として分けておきます。混ぜると、この後の分析が成立しません。

② 溜まった障害を一括で分類させる

定義が固まったら、既存の全件を分類し直します。ここは完全に機械的な作業で、AIに任せて問題ありません。

数十件から数百件を一度に渡すと精度が落ちるので、30〜50件ずつに区切って処理します。出力には分類の根拠を1行で添えさせると、後の確認が一気に楽になります。

判断に迷ったものには印を付けさせます。印が付いたものは、たいてい記述が曖昧な障害です。分類の問題ではなく、記録の問題として起票者に確認します。

③ 分類の揺れを検出させる

分類が終わったら、AI自身に揺れを探させます。

「同じような事象なのに違う分類になっているものを挙げて」と依頼するだけです。人が目視で探すのは非現実的ですが、機械的な突き合わせなら確実に見つかります。

揺れが多い分類は、定義そのものが曖昧というシグナルです。分類名を変えるか、2つに割るかを検討します。

④ 傾向を出させ、打ち手の候補まで書かせる

ここが本来やりたかった工程です。

分類済みのデータを渡し、次を出させます。

• 分類ごとの件数と、その推移
• 検出工程と、本来検出すべき工程のずれが大きい分類
• 特定の機能・担当・工程に偏っているもの
• それぞれに対して考えられる打ち手の候補

2つ目が特に効きます。「単体テストで見つけるべきだったものが、結合テストで大量に出ている」という状態が見えれば、打ち手はテストの強化ではなく、単体テストの観点や完了基準の見直しになります。

テストの消化状況とあわせて見るならテスト進捗管理表、単体テストの中身は単体テスト仕様書兼結果報告書を突き合わせます。

AIに任せてはいけないこと

1. 打ち手を決めること

AIは打ち手の候補を出せますが、どれを実行するかは決められません。残っている期間、体制、顧客との関係、他機能への影響——これらを踏まえた判断は、プロジェクトの文脈を持っている人にしかできません。

「テストケースを増やす」は正しく見えますが、期間が残っていなければ実行不能です。実行できない打ち手を掲げるくらいなら、スコープを削る相談を先にするほうが誠実です。

2. 個人の評価に使うこと

「この分類の障害は、特定の担当に偏っている」という分析結果は簡単に出ます。これを人の評価に使った瞬間に、障害の報告が止まります。

障害が報告されなくなったプロジェクトは、品質が良くなったのではなく、見えなくなっただけです。分析結果は仕組みの問題として扱うと決めておきます。偏りが出たなら、レビュー体制か引き継ぎの問題として読みます。

3. 事実の確認を省くこと

分類結果は必ずサンプリングして確認します。AIは、記述が曖昧な障害を、それらしい分類に入れてしまいます。全件は無理でも、分類ごとに数件ずつ見れば、大きな誤りは検出できます。

分析結果を打ち手に変える

傾向が出たら、打ち手は3種類に整理すると実行に移しやすくなります。

2つ目の横展開が、いちばん費用対効果が高いです。1件の障害から、まだ表面化していない同種の障害を先に潰せます。テストの終盤で同じ不具合が繰り返し出るのは、これをやっていないからです。

打ち手をどう合意し、どう報告するかはテスト計画書・テスト方針書の書き方にまとめています。レビュー段階で検出した指摘はレビュー指摘表で管理し、実装後に顕在化したものを障害管理表へ引き継ぐと、工程ごとの検出状況が正しく集計できます。

うまくいかないときの原因

まとめ

• 原因分類が形骸化するのは、分類を決めるのが早すぎることと、分析する時間が誰の仕事でもないこと
• 分類の定義は、机上で決めず、実際に起きた障害から帰納して作り直す
• 分類・揺れの検出・傾向出しはAIに任せられる。数十件ずつ区切り、根拠を1行添えさせる
• 打ち手を決めること・個人の評価に使うこと・事実確認を省くことは渡さない
• 打ち手は「今すぐ効く／横展開する／次から効く」の3種類に整理する。横展開が最も費用対効果が高い

分類と集計が自動化されると、品質会議の中身が「件数の報告」から「打ち手の相談」に変わります。もともとそこが目的だったはずです。

実際の進め方を手を動かしながら身につけたい方は、AI開発トレーニングで個別にお伝えしています。

それだけ重要なのに、作り方は属人的です。ヒアリングのメモを眺めながら、経験のある人が頭の中で機能に切り分けている、というのが実態ではないでしょうか。

この作業の洗い出しと粒度そろえの部分は、生成AIにかなり任せられます。一方で、任せると見積もりが壊れる判定もはっきり存在します。この記事では、その境界線を含めて手順をまとめます。

任せる範囲の決め方で迷ったときは、AIに何を任せ、何を任せないかが判断の軸になります。

機能一覧とは｜見積もりの土台になる表

機能一覧（システム機能一覧）とは、構築するシステムの機能をすべて並べ、それぞれをどう実現するかまで定義した一覧表です。単なる機能の目録ではありません。

一覧に持たせる列は、おおむね次のようになります。

この表が「目録」ではなく「見積もりの土台」になるのは、実現方法と難易度の2列があるからです。この2列が無い機能一覧は、後工程で作り直しになります。

様式はシステム機能一覧のテンプレートをそのまま使えます。

用意するもの

機能一覧は、ゼロから発明するものではありません。必ず元になる情報があります。

このうち現行システムの画面・帳票・バッチ一覧は、あるなら必ず入れてください。移行案件では、機能の8割がここから導けます。逆にこれを渡さないと、AIは一般的な業務システムの機能を創作します。

手順

① ヒアリングメモから機能候補を洗い出させる

まず、量を出します。この段階で絞らないのがコツです。

ヒアリング記録と業務の全体像を渡し、「この業務を実現するために必要なシステム機能を、抜けなく挙げて」と依頼します。重複や粒度のばらつきは、この時点では気にしません。

人が最初から整った一覧を作ろうとすると、思いつかなかった機能がそのまま抜けます。AIに大量に出させてから削るほうが、抜けが減ります。

② 粒度を揃える

ここが機能一覧づくりの本丸です。洗い出した候補は、粒度がばらばらになっています。

粒度の基準は、「見積もれる単位か」で決めます。

• 粗すぎる（例：「受注管理」）→ 何人日かかるか誰にも答えられない
• 細かすぎる（例：「受注画面の得意先コード入力欄」）→ 一覧が数百行になり、管理そのものが目的化する
• ちょうどよい（例：「受注登録画面」「受注一覧照会画面」「受注確定バッチ」）

実務的には1機能＝1画面／1帳票／1バッチを基準にすると、ほぼ破綻しません。「この機能は何画面ぶんか」と問い返せる状態になっていれば、粒度は足りています。

AIには、基準を明示して揃え直させます。「1機能＝1画面・1帳票・1バッチの単位に分割・統合して」と指示すれば、機械的に整います。

③ 機能分類と業務分類を振らせる

粒度が揃ったら、画面・帳票・バッチの分類と、業務分類（大・中・小）を振ります。この作業は完全に機械的なので、そのまま任せて構いません。

業務分類は後で並び替えと集計に使います。ここが揃っていないと、「業務ごとに何機能あるか」が出せず、体制の検討に使えません。

④ 重複と抜けを突き合わせさせる

一覧ができたら、AIに自分の出力を検査させます。

• 名前は違うが実質同じ機能になっていないか
• 登録があるのに照会・修正・削除が抜けていないか
• 帳票を出す機能はあるのに、出力対象データを作る機能が無い、といった不整合はないか

登録はあるが一覧照会が抜けている——これは実際によくある抜けです。人が作った一覧でも頻繁に起きます。機械的な突き合わせは、AIが人より確実に見つけます。

現行システムの一覧があるなら、それとも突き合わせます。「現行にあって新機能一覧に無いもの」を出させると、移行漏れが一度に洗えます。

標準機能で足りるかの判定は、AIに任せない

ここが最も重要な線引きです。

「この機能は、パッケージやプラットフォームの標準設定で実現できるか。それとも開発が必要か」——この判定をAIに任せると、見積もりが根本から狂います。

理由は3つあります。

1. 製品のバージョンと契約内容に依存する 同じ機能でも、エディションやライセンス、有効化されているオプションによって、標準で足りるかどうかが変わります。AIは一般論で答えます。

2. 「できる」と「実用に耐える」は違う 標準機能で形は作れても、件数や同時実行数の条件で使い物にならない、というケースは頻繁にあります。この判断には実際の運用条件が要ります。

3. 間違えたときの損害が大きい 「標準で足りる」と誤判定した機能は、見積もりから開発工数が抜け落ちます。設計フェーズの終盤で発覚し、そのまま赤字要因になります。

したがって、実現方法の列は候補を挙げさせるところまでをAI、判定は人が持ちます。「標準で実現する場合の方法と、開発する場合の方法を両方挙げて」と依頼し、どちらを採るかは自分で決めます。

難易度と工数見積もりへの繋げ方

難易度の列は、機能一覧が見積もりに繋がる要です。

難易度は絶対的な基準ではなく、自社の基準に揃えるものです。「高・中・低」でも「1〜5」でも構いませんが、それぞれが何人日相当かを先に決めておきます。決めずに難易度だけ振っても、合計が出せません。

AIの使い方としては、基準を渡してから一括で振らせるのが有効です。

難易度の定義（低＝◯人日、中＝◯人日、高＝◯人日）を渡したうえで、 「この定義に照らして、各機能の難易度を振って。判断に迷ったものは印を付けて」

迷ったものに印を付けさせるのが要点です。全件を人がレビューするのは大変ですが、印の付いたものだけなら現実的に見られます。そして、迷いが出るのはたいてい要件が固まっていない機能です。難易度づけは、要件の曖昧さを炙り出す工程でもあります。

標準機能で足りるかの判定結果は、FIT&GAP分析一覧と揃えておくと、後の要件確定がスムーズになります。

うまくいかないときの原因

まとめ

• 機能一覧は目録ではなく、実現方法と難易度の2列があって初めて見積もりの土台になる
• 洗い出しは絞らず量を出す。 人が最初から整えようとすると、思いつかなかった機能が抜ける
• 粒度は1機能＝1画面・1帳票・1バッチを基準にすると破綻しにくい
• 標準機能で足りるかの判定は人が持つ。 誤判定は見積もりから工数が抜け落ち、そのまま赤字要因になる
• 難易度は定義を先に決めてから振らせ、迷ったものに印を付けさせる。印はそのまま要件の曖昧さを示す

洗い出しと整形をAIに任せられるようになると、空いた時間を実現方法の判定と、要件の詰めに回せます。機能一覧の精度を決めているのは、もともとそちらです。

進め方を実際に手を動かしながら身につけたい方は、AI開発トレーニングで個別にお伝えしています。

設計書づくりでいちばん時間を食うのは、様式を整えることではありません。項目を1つずつ埋めていく作業です。画面定義書なら、項目名・型・桁数・必須有無・初期値・入力チェック・表示条件を、画面の数だけ書くことになります。

この部分は、生成AIにかなりの割合を任せられます。ただし任せられる範囲と、任せてはいけない範囲がはっきり分かれます。この記事では、要件メモから画面定義書を起こす具体的な手順と、その境界線をまとめます。

設計書に限らず、どの作業をどこまで任せてよいかで迷うことがあります。判断の軸そのものはAIに何を任せ、何を任せないかで整理しています。

なぜ設計書はAIと相性がいいのか

設計書の記述には、元になる情報が必ずどこかに存在しているという特徴があります。

業務のヒアリングメモ、既存システムの画面、Excelの管理台帳、あるいは口頭で決まった仕様のチャット履歴。設計書を書く作業の大部分は、ゼロから発明することではなく、散らばっている情報を決まった形式に整えることです。

そして「散らばった情報を、決まった形式に整える」は、生成AIが最も得意とする作業です。

逆に言えば、元になる情報が無い状態でAIに投げても、それらしい嘘が返ってくるだけです。ここが最初の分岐点になります。

用意するもの

手順に入る前に、入力を揃えます。ここが揃っていないと、後の工程がすべて空回りします。

4つ目が意外と重要です。出力先の様式を先に見せておくと、そのまま貼り付けられる形で返ってきます。 様式を渡さずに書かせると、整形し直す手間が発生し、時短になりません。

様式は画面定義書のテンプレートをそのまま使えます。

手順

① 項目定義を起こさせる

最初に作るのは項目定義です。画面に載せる項目を、型・桁数・必須有無・初期値まで含めて一覧にします。

このとき、業務の説明と扱うデータを一緒に渡すのが要点です。項目名だけを渡すと、型や桁数は一般的な値で埋められます。「この項目は何のために存在するのか」が分かっていれば、AIは適切な型を選べます。

出てきた一覧は、そのまま採用せず次の3点だけを人が確認します。

• 桁数：業務上の最大値を反映しているか（AIは無難な値を置きたがります）
• 必須有無：運用上、空で登録される場面が本当に無いか
• 初期値：登録時と更新時で挙動が変わらないか

② 入力チェックと表示条件を詰める

項目が固まったら、チェック仕様と表示条件を書かせます。ここはAIが得意な領域です。

「この項目とこの項目は、どちらか一方が必須」「この区分のときだけ表示する」といった条件の網羅は、人が手で書くと必ず漏れます。AIに一度洗い出させてから、不要なものを削るほうが速く、そして漏れません。

足し算より引き算にするのがコツです。「考えられるチェックを全部挙げて」と依頼し、そこから落としていきます。

画面に出すメッセージの文言と、選択リストの値は、それぞれ別の資料に切り出しておくと後の変更が楽になります。

• メッセージ設計書のテンプレート
• 選択リスト定義書のテンプレート

③ 画面間の整合を取る

1画面ずつ作っていくと、画面をまたいだところで必ず矛盾が出ます。同じデータなのに画面Aでは必須、画面Bでは任意。同じ項目名なのに桁数が違う。

ここでのAIの使い方は、書かせることではなく突き合わせさせることです。作成済みの複数画面の項目定義をまとめて渡し、「同じ項目で定義が食い違っているものを挙げて」と聞きます。

この用途は、人がやると見落とすがAIは見落とさない、という典型例です。画面全体の構成は画面一覧、遷移の流れは画面遷移図で管理し、そちらとも突き合わせます。

④ レビュー観点で自己点検させる

提出前に、レビューする側の視点で自分の成果物を点検させます。

「この設計書をレビューする立場で、指摘すべき点を挙げて」と依頼するだけです。実際のレビューで出る指摘の何割かは、この時点で潰せます。

観点を明示的に渡すと精度が上がります。何を見るべきかは設計・開発・テストのレビュー観点にまとめています。

AIに任せてはいけないところ

ここが本題です。次の3つを渡すと、成果物の価値そのものが失われます。

1. 業務上の判断

「この項目は必須にすべきか」は、技術の問題ではなく業務の問題です。必須にすれば入力漏れは防げますが、現場が値を持っていない場面があれば運用が止まります。

AIはこの判断を「一般的にはこうです」で埋めてきます。もっともらしく見えるので、そのまま通ってしまうのがいちばん危険です。

2. 決まっていないことを決めること

仕様が固まっていない箇所をAIに投げると、決まっていないという事実が消えます。何かが書かれた設計書は「決まったもの」として下流に流れ、実装され、テストで初めて食い違いが露見します。

未決事項は未決事項として残すのが正解です。空欄のままにする、あるいは「要確認」と明記して、決める場に持ち込みます。

3. 最終的な事実確認

出力された内容が、実際のデータや既存システムの挙動と一致しているか。ここは必ず現物で確認します。

AIは、それらしい嘘を、正しい文章と同じ自信で書きます。 設計書は下流の全工程の前提になるため、誤りが1つ紛れ込むと、実装とテストの両方をやり直すことになります。

うまくいかないときの原因

いちばん多いのは1番目です。入力の質が、そのまま出力の質になります。

この作業で何が変わるか

正直に書くと、AIを使っても設計書づくりが一瞬で終わるわけではありません。

変わるのは、時間の使い道です。項目を1つずつ書き写す作業と、様式を整える作業がほぼ無くなります。その分を、業務上の判断と、未決事項を決める場づくりに回せます。

設計書の品質を決めているのは、もともと後者です。前者に時間を取られて後者が薄くなっていたのが、多くのプロジェクトの実態でした。そこが入れ替わるというのが、この作業のいちばん大きな効果だと考えています。

まとめ

• 設計書は元になる情報が必ず存在するため、生成AIと相性がよい
• 入力を4つ揃える。出力先の様式を先に渡すと、貼り付けられる形で返ってくる
• 手順は項目定義 → チェックと表示条件 → 画面間の整合 → 自己点検の4ステップ
• 業務上の判断・未決事項の決定・事実確認は人が持つ。 ここを渡すと成果物の価値が消える
• 変わるのは総時間より時間の使い道。書き写す作業が減り、決める作業に回せる

実際にどう指示を組み立てるか、どこまで一度に投げるかは、扱うシステムや体制によって変わります。手を動かしながら身につけたい方は、AI開発トレーニングで個別にお伝えしています。

私たちが公開してきた無料ドキュメントテンプレートは、ありがたいことに多くの方に継続的にご活用いただいています。プロジェクト計画書、要件定義書、テスト進捗管理表——IT導入プロジェクトの現場で実際に使う成果物を、工程別に揃えたシリーズです。

うれしい反響をいただくなかで、次第にはっきりしてきたことがありました。「ここまでできるなら、もう一歩先まで面倒を見てほしい」というご要望です。

この記事では、そのご要望の中身と、Premium Document Templates をゼロから設計し直すに至った思想を公開します。

なお、無料テンプレートは今もこちらで公開しています。実物を見てから読み進めていただいても構いません。

利用者から寄せられた、3つのご要望

反響のなかで繰り返し届いたご要望は、驚くほど共通していました。そしてそのすべてが、テンプレートというファイルの「外側」に関する話でした。

ご要望1: 「何を書くか」の指針もほしい

最も多かったのがこれです。「スコープ」という枠があっても、そこに何をどの粒度で書けば決裁が通るのか——その判断は、書き手の経験に委ねられます。

「枠は完璧なので、あとは書き方の勘所も一緒に教えてほしい」。裏を返せば、テンプレートは枠を提供するだけでなく、思考の順序まで導けるはずというご期待でした。

ご要望2: 自社カラーへの反映をもっと速く

「そのまま使っても十分だが、自社のブランドカラーに揃えて提出したい」という声も多くいただきました。

ところが一般的なPPTXは、表紙・章扉・ガント・KPIチャートで色指定が個別になっているため、統一に手間がかかります。体裁の調整に使う時間を、リスクや体制の検討に回したい。まっとうなご要望です。

ご要望3: 作った後の更新まで楽にしたい

そして最も本質的だったのがこれです。計画書は生き物で、スケジュールもリスクも週単位で変わります。

「初版を作るのは速くなった。次は更新のほうを軽くしてほしい」。テンプレートの価値を、作成時点だけでなく運用フェーズまで広げてほしいというご要望でした。

転換点：テンプレートを「ファイル」から「仕組み」へ

3つのご要望に共通していたのは、ファイルを1枚渡すだけでは応えきれないという点でした。より綺麗なファイルを作っても、書き方の指針も、体裁の統一も、更新の軽さも生まれません。

そこで発想を変えました。

完成品のファイルを配るのではなく、成果物を生成するスキルと、その出力先となるテンプレートをセットで届ける。

プレミアムテンプレートは、この転換から生まれています。まず「何を届けるのか」を具体的に説明し、そのあとに設計を支える3つの原則を書きます。

届けるものの中身：生成スキル + テンプレート

「仕組み」と書くと抽象的なので、具体的に何をお渡しするのかを書きます。セットは2つの要素で構成されています。

1. 生成スキル

対話しながら必要な情報を引き出し、成果物を出力するスキルです。データを渡せば、体裁の整った成果物がそのまま出てきます。書式の調整も、図の貼り付けも、こちらの仕事です。

2. 出力テンプレート

スキルが出力する先の型です。3テーマの配色・タイポグラフィ・レイアウトで統制済みなので、どのプロジェクトで生成しても品質がぶれません。

実例：LWC画面定義書は23シート構成

たとえばSalesforceのLWC画面設計書を生成するスキルは、23シート構成の画面定義書を出力します。

目次と読み方ガイドに加え、画面概要、LWC構成、コンポーネント公開設定、datatable列定義、DTO・Apex仕様、画面レイアウト、画面項目定義、入力チェック、表示条件、画面入出力処理設計、オブジェクト・SOQL、選択リスト値、メッセージ一覧、権限・FLS、画面遷移、シーケンス・状態遷移、非機能要件、テスト設計、未決事項——実装とレビューに必要な観点を網羅しています。

画面遷移図・シーケンス図・状態遷移図はソースから生成してExcelに貼り込み、実画面のスクリーンショットも自動でキャプチャして配置します。レビュアがシートを往復しなくても、開いた1枚で意味が通ることを設計基準にしました。

もちろんこれも Navy / Graphite / Bordeaux の3テーマで出力できます。スライドもExcelも、同じ配色体系の上に載っています。

設計思想1：PMBOK第7版に準拠したプロジェクト計画書の構成

プロジェクト計画書テンプレートの全10スライドは、PMBOK第7版とIPA共通フレーム2013の考え方に沿って構成しました。表紙、エグゼクティブサマリー、スコープ、体制、マスタスケジュール、リスク管理、品質管理、コミュニケーション計画、変更管理、クロージング。

重要なのは順番です。決裁者が読む順序と、書き手が考える順序を一致させています。スコープが固まってから体制、体制が決まってからスケジュール。現場で有効だった思考の順序を、構造そのものに埋め込みました。

さらに各スライドには「書くべきこと」を明記しています。たとえばスコープなら「やること」だけでなく「やらないこと」まで書けるようにする。ここを押さえておくと、後工程の合意形成が驚くほどスムーズになります。

この「やらないことを明記する」という一項目は、私自身が20年以上のプロジェクトで最も多くの手戻りを見てきた場所です。スコープの穴は、要件定義ではなく受入テストのタイミングで牙をむく。だからテンプレートの側で先に問うことにしました。

枠を埋めていけば、自然と論理が通る。これがご要望1への回答です。

設計思想2：資料デザインをシステム化し、配色を統一する

色・フォント・余白を、スライド単位ではなくシステム単位で定義しました。

• カラー: テーマごとにベース色・アクセント色・共通のシャンパンゴールドを定義し、全スライドで同一トークンを参照
• タイポグラフィ: Noto Sans JPに統一。和文プロポーショナル詰めまで指定
• レイアウト: 表紙・章扉・本文・図表の4パターンに集約し、例外を作らない

たとえば戦略・経営層向けの「Executive Navy」はディープネイビー #003A70 を主役に、スカイブルー #00A3E0 をデータ可視化とCTAの誘導色として使い分けています。

色を「なんとなく綺麗だから」ではなく、役割で決める。この設計により、カラートークンを差し替えるだけで全スライドに反映されます。外資コンサル品質を、センスではなく再現性のあるものにする条件でした。ご要望2への回答です。

設計思想3：AI駆動でドキュメントを自動生成し、更新を軽くする

最後がご要望3への回答です。テンプレートをAI駆動開発の仕組みと接続し、プロジェクト情報を渡すだけで表紙から章扉、ガントチャート、KPIチャートまでを生成できるようにしました。

この方式の価値は、生成が速いことだけではありません。更新が軽いことです。

スケジュールが変われば、変更後のデータを渡し直すだけで資料が最新化される。計画書が、作って終わりの成果物ではなく、プロジェクトと一緒に動く資産になります。

そしてこの仕組みに乗せられるのは、計画書だけではありません。設計書も、進捗報告資料も、同じ設計思想の上に載ります。成果物の種類が増えても、品質を担保する仕組みは1つで済む——ここが、単体のテンプレートでは到達できない領域です。

なお、この「データを渡せば資料が生成される仕組み」は、特別なシステムを買わなくても構築できます。一度作ってしまえば、計画書も報告書も議事録も同じ仕組みに乗せられる。資料作成という業務そのものが変わります。

実際に私が構築した手順そのものを、1on1のトレーニングでお伝えしています。

▼ AI開発トレーニングで、この仕組みの作り方を学ぶ

なぜ3テーマなのか｜資料の配色が読み手に与える印象

もうひとつ、よくいただく質問に答えておきます。なぜ単一テーマではなく3つ用意したのか。

資料の色は、読み手に与える印象を決める言語だからです。同じ内容でも、戦略提案と、老舗企業向けの報告と、ラグジュアリーブランドの企画では、適した色が違います。

• Executive Navy — 戦略・経営。知性と正統性を象徴する深い青
• Executive Graphite — 落ち着いた信頼感。業種を選ばない中庸なトーン
• Vintage Bordeaux — 伝統・ラグジュアリー。重みと格を伝える深紅

3テーマとも共通のシャンパンゴールドをアクセントに持たせ、ブランドファミリーとしての一貫性を保っています。テーマを変えても、品質の水準は変わりません。

▼ 3テーマの全スライド（各10枚）を実物で確認する

今後のラインナップ

同じ設計思想で、成果物の種類を順次広げていく予定です。

• プロジェクト計画書 — PMBOK第7版準拠の10スライド構成
• 進捗報告資料 — 週次・月次のステータスレポート
• 設計書 — LWC画面定義書をはじめとする詳細設計ドキュメント

いずれも生成スキルと出力テンプレートのセットでの提供を予定しています。提供時期や詳細については、お問い合わせいただければ個別にご案内します。

この記事を書いた人

IT業界20年以上、Salesforce を中心としたシステム導入プロジェクトで要件定義からPM・アーキテクト業務まで一貫して担当。ここで公開しているテンプレートは、実案件で自ら作り続けてきた成果物を汎用化したものです。「現場で本当に使われる資料とは何か」を、経験そのものから設計に落とし込んでいます。MENTA でのメンタリング契約は累計36件、評価は★5.0。

▼ プロフィール詳細

まとめ

無料テンプレートを公開し続けるなかで見えてきたことは、シンプルでした。

1. 求められているのは、より綺麗なファイルではなく「書き方の指針・体裁の統一・更新の軽さ」の3点
2. 標準準拠の構造とデザインシステムがあれば、品質は再現できる
3. 生成スキルとテンプレートをセットで届ければ、成果物の種類が増えても品質を担保する仕組みは1つで済む

まず実物を見たい方へ

構造・配色・図表のクオリティは、説明よりスライドを1枚見たほうが早いはずです。3テーマ×全スライドを、そのまま公開しています。

▼ Premium Document Templates を確認する

自分で作れるようになりたい方へ

テンプレートを「使う側」から「作る側」へ。ドキュメント生成の仕組みそのものを構築できるようになる1on1トレーニングです。無料相談も承っています。

▼ AI開発トレーニングの詳細を見る

ご質問はお問い合わせフォームからどうぞ。

よくある質問

Q. 無料テンプレートと有料テンプレートの違いは？

A. 無料版は実務で使える「枠」を提供しています。有料版はそれに加えて、デザインシステムによる体裁の統一と、データからの再生成による更新の軽さを備えています。継続的に資料を作り、更新し続ける立場の方ほど効果が出ます。

Q. 自社のブランドカラーに変えられますか？

A. カラートークンを差し替えるだけで全スライドに反映される設計です。スライドを1枚ずつ直す必要はありません。これがデザインシステム化の目的です。

Q. どのテーマを選べばいいですか？

A. 読み手で決めてください。経営・戦略層への提案ならNavy、業種を選ばず落ち着いた印象にしたいならGraphite、伝統・ラグジュアリー系のブランドならBordeauxが適します。

Q. 「生成スキルとテンプレートのセット」とは具体的に何ですか？

A. 対話しながら成果物を出力する生成スキルと、その出力先となるテンプレート（3テーマの配色・レイアウトで統制済み）の2点セットです。データを渡すと、体裁の整った成果物がそのまま出てきます。

Q. スライドだけでなく、Excelの設計書も対象ですか？

A. 対象です。実例としてLWC画面定義書を23シート構成で生成できます。画面項目定義から権限・FLS、テスト設計まで網羅し、画面遷移図やスクリーンショットの貼り込みまで自動化しています。スライドもExcelも、同じ3テーマの配色体系の上に載っています。

Q. この仕組みを自分で作れるようになりますか？

A. なります。特別なシステムは必要なく、データを渡せば資料が生成される仕組みは自分で構築できます。実際に私が構築した手順を、1on1のAI開発トレーニングでそのままお伝えしています。無料相談も承っています。

この問題を解決するために開発したのが、CloudFormGenerator（帳票ジェネレータ）です。Salesforceネイティブの帳票生成ツールで、社内で長年使ってきたWordテンプレをそのまま活かしながら、商談レコードから1クリックで見積書・請求書・契約書をPDF出力できます。

この記事では、CloudFormGeneratorの全機能と、競合製品との差別化ポイントを解説します。

Salesforce帳票業務の3つの無駄

Salesforceを導入しても、帳票業務だけ「昔ながらの手作業」が残り続けるのには理由があります。

転記ミスと二重管理。 商談の金額・顧客名・担当者をSalesforceに入力した後、同じデータをWordファイルにも手で転記します。このダブルエントリーは入力ミスの温床です。

テンプレートの属人化。 「最新の見積書フォーマット、誰が持ってるんだっけ？」問題です。担当者のPCにばらばらに保存されたWordファイルは、会社の書式が変わるたびに全員への配布作業が発生し、バージョン管理が崩壊します。

IT部門への依存。 既存の帳票ツールの多くは、WordファイルへのAPIタグ直接記述方式です。業務担当者がWordを開いてコードを書くのは現実的ではなく、テンプレートを変えるたびにIT担当者や外部SIerへの依頼が必要になります。「書式を少し変えたいだけで1ヶ月待ち」という状況が生まれます。

CloudFormGeneratorとは

CloudFormGeneratorは「SalesforceのデータをそのままPDF帳票にする」に特化したSalesforceネイティブのソリューションです。LWC（Lightning Web Component）とApexのみで構成しており、外部サーバーへのデータ送信は一切不要。Salesforceのシェアリングルール・FLS（項目レベルセキュリティ）がそのまま適用されます。

商談レコードの「帳票出力」ボタンをクリックするだけで、Salesforceに登録済みの顧客名・商品明細・金額・担当者が帳票テンプレートに自動で流し込まれ、PDFとしてダウンロードおよびレコードへの添付ができます。

主要競合製品と徹底比較

Salesforce向け帳票ツールの市場には複数の製品（以下、製品A〜Cとします）があります。機能の豊富さには定評がある半面、中小企業での導入にはいくつかの課題があります。

価格の壁。 製品A（海外系）は10ユーザー想定で月額約¥35,000、製品B（海外系）は約¥28,000、製品C（国内系）は¥30,000〜100,000と、中小企業にとって重い固定費です。CloudFormGeneratorは出力件数無制限。個人開発の低コスト構造により、競合製品を下回る価格帯での提供が可能です。料金はご利用規模に応じて個別にお見積もりいたします。

設定の複雑さ。 製品A・製品B系は「WordファイルへのAPIタグ直接記述」方式です。{{OpportunityName}}のようなタグをWord上に手書きする必要があり、設定に必ずIT担当者が介在します。CloudFormGeneratorはビジュアルなマッピング画面で、業務担当者がドロップダウンで項目を選ぶだけで設定できます。

Salesforceネイティブかどうか。 製品A・製品BはSalesforceとの連携に外部API接続が必要です。OAuthトークン管理・エンドポイント設定・セキュリティポリシーの承認など、導入にひと手間かかります。CloudFormGeneratorはSalesforce内で完結するため、情報システム部門の承認を得やすいのも特長です。

製品	月額（10U想定）	設定方式	Salesforceネイティブ	印鑑対応
製品A（海外系）	¥35,000〜	Wordタグ直接記述（IT必須）	外部API
製品B（海外系）	¥28,000〜	Wordタグ直接記述（IT必須）	外部API
製品C（国内系）	¥30,000〜	専用エディタ	外部サーバー	△
CloudFormGenerator	お見積もり	ビジュアルマッピング（ノーコード）	LWC+Apex完結	SVG自動生成

5つの差別化ポイント

1. 既存WordテンプレをそのままアップロードするだけでOK

CloudFormGeneratorの最大の特長は、社内で長年使ってきた.docxファイルをそのまま流用できる点です。「ファイルをドロップ」するだけで、テンプレート内の{{顧客名}}や{{合計金額}}といったプレースホルダーを自動検出します。

会社の書式・フォント・印鑑欄のレイアウト・ロゴ配置はそのまま。「新しいフォーマットに作り直す手間」がありません。白紙から作る場合は「白紙から作成（ページサイズを選択）」モードも選べます。

2. 直感的なマッピング設定 — ドリルダウンで5階層まで辿れる

プレースホルダーとSalesforce項目の対応付けは、ドロップダウンで項目を選ぶだけです。

{{顧客名}} → Account.Name、{{合計金額}} → Amount（通貨フォーマット：¥#,##0）のように直感的に設定できます。親子リレーションは5階層まで辿れるドリルダウン方式で、Opportunity → Account → Owner.Nameのような深い参照も設定可能です。

3. WYSIWYGレイアウトエディタ — 印鑑・明細テーブルを自由配置

白紙からテンプレートを作る場合や、既存テンプレートのレイアウトを変更する場合は、3カラム構成の全画面エディタを使います。

追加できる要素は以下の通りです：

• 固定文字列・セクション見出し・区切り線
• ラベル＋値（Salesforce項目の差し込み）
• 明細テーブル（子レコードを自動展開、ページをまたいでもヘッダーが繰り返し表示、奇数行・偶数行に個別背景色を設定可能）
• 固定テーブル（静的な表、行を自由に追加・削除）
• 今日の日付・ページ番号
• 印鑑（画像印鑑 / テキストからSVG自動生成の文字印鑑）
• バーコード / QRコード（6種類対応：Code128・JAN-13・JAN-8・Code39・NW-7・ITF-14。Salesforce項目の値をそのままコード化して帳票に印字）

明細テーブルでは{{CALC(SUM(Row.金額) * 0.1)}}のような計算式で消費税の自動計算にも対応しています。奇数行・偶数行に別々の背景色を設定するゼブラストライプも標準で設定可能で、行数が多い明細表の視認性を高めます。

エディタ内の「プレビュー」ボタンで、実際のSalesforceデータを反映した帳票の仕上がりをリアルタイムで確認できます。

4. 日本市場特化の印鑑機能

日本企業の帳票に欠かせない「印鑑」に正式対応しています。

印鑑マスタで社印・個人印を登録し、テンプレートに配置するだけで、出力PDFに印鑑が自動で入ります。手書きモードではタブレットやマウスで直接描画した印影を登録することも可能です。

5. PDF出力 — 標準版と大容量対応VF版の2択

出力形式はPDF一択で2種類を用意しています。

PDF（標準）は通常の帳票に使用します。PDF（大容量対応・VF版）は明細行が多い・画像が大きいなど、Apex処理のヒープサイズ6MB制限を超えるケースに対応しています。出力後はSalesforceのメモ＆添付ファイルに自動保存されます。

フォントの選択肢と出力方式ごとの注意事項

レイアウトエディタでは、テンプレート全体の既定フォントと各要素個別のフォントを2階層で指定できます。

PDF（標準）はフォント制限なし。ブラウザのChromiumエンジンでPDFを生成するため、OSにインストール済みの日本語フォント（メイリオ・游ゴシック・游明朝等）をすべて使用できます。

PDF（大容量VF版）はArial Unicode Msのみ。SalesforceサーバーサイドのFlying Saucerエンジンで処理するため、使用できるフォントは「ゴシック（標準）= Arial Unicode MS」のみです。大容量対応が必要な帳票でフォントのバリエーションが必要な場合は、テンプレートをPDF（標準）で出力できるサイズに収めることをご検討ください。

帳票出力のフロー — 操作3ステップで完結

実際の操作は非常にシンプルです。

Step 1: レコードページの「帳票出力」ボタンをクリック

Step 2: テンプレートを選択し、PDF標準 or VF版を選択。「このレコードにファイルを添付する」チェックボックスで自動保存も設定可能

Step 3: 「プレビュー」で確認後、「出力」ボタンでPDFをダウンロード

出力完了後はメモ＆添付ファイルにPDFが自動保存されます。

備考の表示位置も自在にコントロール

備考・注意事項の表示位置を帳票テンプレートごとに設定できます。

ページをまたぐ大量明細の帳票でも、備考や注意事項を「必ず最終ページに表示する」設定が可能です。ページ数が変動する帳票で「備考が途中のページに出てしまう」問題を解消します。

出力帳票サンプル

実際に出力したPDFの品質を確認してください。

こんな組織・担当者におすすめ

• 中小企業の経理・営業事務 — 見積書・請求書を月50〜500件発行している。ExcelやWordのコピペ作業に限界を感じている
• Salesforce管理者 — 開発者なしで帳票テンプレートを運用したい。IT部門への依頼なしに業務担当者が自分で管理できる体制を作りたい
• 製造業・IT企業のシステム担当 — 印鑑・日本語フォント対応が必要。既存の会社フォーマットをそのまま活かしたい
• Salesforce DX推進担当 — 「入力はSalesforceに統一したのに、帳票だけ別管理」という矛盾を解消したい

まとめ

• 既存WordテンプレをそのままPDF帳票に — アップロードするだけでプレースホルダーを自動検出。書式・印鑑欄の作り直し不要
• ビジュアルマッピングでノーコード設定 — IT部門への依頼なし。業務担当者が自分でテンプレートを管理できる
• 競合製品より低コスト — 出力件数無制限・ユーザー数課金なし。固定費で予算管理しやすい
• Salesforceネイティブで追加サーバー不要 — 外部API接続なし、セキュリティポリシーをそのまま維持
• 日本市場特化の印鑑機能 — テキスト入力・手書き両対応のSVG印鑑を標準搭載

帳票業務の「Salesforceにデータがあるのに手作業」という矛盾を解消する一手として、ぜひCloudFormGeneratorをお試しください。

CloudFormGenerator 評価版インストール手順はこちら →