「取引先の与信額を超えたら商談を登録できないようにしたい」と頼むと、トリガが返ってきます。入力規則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開発トレーニングで個別にお伝えしています。

Vibe Codingとは何か（感覚的・直感的なコーディング手法）

Vibe Coding（バイブコーディング）とは、従来の詳細な設計書やドキュメントベースの開発から脱却し、開発者の直感と感覚、そしてAIの支援を活用した新しいコーディング手法です。

開発者が「こんな機能を作りたい」という漠然としたアイデアや要求を、AIエディタとの対話を通じて具体的なコードに変換していくため、完璧な設計よりもスピードや柔軟性を重視しており、Salesforceの開発と非常に相性がよい手法となります。

サポーターさん

Vibe Codingを使えば、開発が必要な画面や機能も要件定義の段階でプロトタイプをサクッと作ったり、設計書や開発のコーディングのベースを作成して開発を大幅に効率化できます

従来のSalesforce開発の課題を解消

Salesforceの開発では、Javaなどの言語は経験があるが、ApexやLWCは経験がないというメンバーがアサインされることもありますが、Vibe codingを行うことで、Salesforce独自の言語（Apex/LWC/Visualforce/SOQL/SOSL）への対応やガバナ―制限への対応もAIが自動的に対応してくれるため、キャッチアップも用意で、開発効率も大幅にアップすることができます。

作成されたソースコードについて仕様や解説もしてくれるしコメントを入れることができるので、処理内容を把握して、要件と異なるところもすぐに検索して修正することができます。

AIエディタで実現できること

AIエディタとは？

開発現場で、皆さんが一番利用している生成AIは何でしょうか？実際はコーディング以外の作業もあるのでChatGTPが一番多いかもしれませんね。

コーディングで利用するAI エディター（※1）については、「GitHub Copilot」「Cline」「Cursor」「Windsurf」「Claude Code」 など数多くのエディタが出てきてますが、それぞれ一長一短があるような印象です。

ちなみに私は、現時点ではClaude Codeが一番のお気に入りです。Salesforceの開発IDEとしてはVisual Studio Codeが一般的になってきてますが、Claude Code はVSCodeの拡張プラグインとして利用することができます。

CursorやWindsurfは、VSCode のフォークエディタの位置づけとなります。

※1.AIエディタとは、AI（人工知能）技術を活用して、文章作成やコード編集などの作業を支援するソフトウェアで、コード補完やエラーチェック、自動生成などの機能を持ちます。

Salesforceの開発ではVSCodeを利用することが多いと思うので、現時点では、VSCodeと相性の良いものを選択するのがいいかもしれません。現在はまだ過渡期なので、特定のエディタというよりは、ChatpGPTやCluade.aiを使ってソースコードを生成して利用するなど組み合わせで進めていくのもよいと思います。

エディタについては、開発者ごとにこだわりが強く表れるので、まずは使ってみて気に入ったものを見つけるところから始めてください

主要AIエディタの比較

比較表

項目	GitHub Copilot	Cline	Cursor	Windsurf	Claude Code
料金	$10/月	無料/有料プラン	$20/月	$15/月	無料（プレビュー）
統合性	多エディタ対応	VS Code専用	専用エディタ	専用エディタ	コマンドライン
Salesforce対応
コード補完	非常に高精度	高精度	高精度	高精度	中程度
ファイル操作	限定的	可能	可能	可能	可能
学習コスト	低	中	低	中	高

GitHub Copilot の詳細分析

概要と特徴 GitHub Copilotは、OpenAIのCodexモデルをベースとしたAIコーディング支援ツールです。GitHub上の膨大なオープンソースコードで訓練されており、多言語に対応しています。Salesforce開発においては、ApexやLightning Web Componentsのコード補完に優れた性能を発揮します。

Salesforce開発における強み

• Apex言語の高精度な補完とコード生成
• Lightning Web Componentsのテンプレート自動生成
• SOQLクエリの最適化提案
• テストクラスの自動生成
• Salesforce APIの適切な使用方法提案

Cline の詳細分析

概要と特徴 ClineはVS Code拡張として動作するAIアシスタントで、ファイル操作やターミナル操作が可能な点が特徴です。Salesforce開発においては、Salesforce CLIとの連携や、複数ファイルにまたがる機能実装に威力を発揮します。

Salesforce開発における活用方法

• Salesforce CLIコマンドの自動実行
• プロジェクト構造の自動生成
• 設定ファイルの一括更新
• デプロイメントスクリプトの作成

Cursor の詳細分析

概要と特徴 CursorはAI機能を内蔵した専用エディタで、自然言語でのコード編集指示が可能です。コードベース全体を理解した上での提案を行うため、Salesforceの複雑なオブジェクト関係を理解した開発が可能になります。

Salesforce開発における強み

• 自然言語でのApexクラス生成指示
• オブジェクト関係を考慮したコード提案
• Lightning Web Componentの統合的な開発支援
• プロジェクト全体の一貫性チェック

Windsurf の詳細分析

概要と特徴 WindsurfはCodeium社が開発したAI統合開発環境で、マルチファイル編集とプロジェクト全体の理解に優れています。Salesforce開発においては、複雑なビジネスプロセスの実装や、大規模プロジェクトの管理に特に有効です。

Salesforce開発における特徴

• 複数のApexクラス間の依存関係管理
• Lightning Web Componentとバックエンドの連携設計
• カスタムオブジェクトとコードの同期的開発
• エンタープライズレベルのアーキテクチャ提案

Claude Code の詳細分析

概要と特徴 Claude CodeはAnthropic製のコマンドライン型AIツールで、ターミナルから直接Claude AIを活用できます。Salesforce開発においては、複雑なロジック実装や、アーキテクチャレベルの意思決定に強みを発揮します。

Salesforce開発における活用シーン

• 複雑なビジネスロジックの設計相談
• パフォーマンスチューニング戦略の策定
• セキュリティ要件の実装方法検討
• 大規模データ移行戦略の立案

AIエディタとSalesforce開発の相性

Salesforce特有の開発要素への対応

Apex言語の特殊性 ApexはJavaライクな構文を持ちながら、Salesforceプラットフォーム特有の制約とオブジェクトモデルを持っています。AIエディタは、標準的なJavaの知識を持つ開発者でも、Salesforce特有の書き方（sObjectの操作、SOQL埋め込み、ガバナーリミット対応など）を自然に習得できるよう支援します。

// AIエディタが提案する効率的なApexコード例
public class ContactProcessor {
    public static void updateContactsByAccount(Set<Id> accountIds) {
        // バルク処理を意識したSOQL
        List<Contact> contactsToUpdate = [
                      SELECT Id, AccountId, LastName 
                      FROM Contact 
                      WHERE AccountId IN :accountIds
                  ];
        
        for (Contact contact : contactsToUpdate) {
            // ビジネスロジックをここに記述
            contact.LastModifiedById = UserInfo.getUserId();
        }
        
        // DML操作もバルク処理
        if (!contactsToUpdate.isEmpty()) {
            Database.update(contactsToUpdate, false);
        }
    }
}

Lightning Web Componentsの複雑性 LWCは、HTML、JavaScript、CSSの組み合わせに加え、Salesforce特有のデコレータやワイヤーサービスの理解が必要です。AIエディタは、これらの複雑な連携を自然な形で提案し、モダンなWeb開発の知識をSalesforceプラットフォームに適用できるよう支援します。

SOQL/SOSLの最適化 データクエリの最適化は、Salesforce開発において極めて重要です。AIエディタは、パフォーマンスを考慮したクエリの作成、適切なインデックス活用、クエリプランの最適化などを支援します。

AIエディタによる開発効率化のポイント

コンテキスト理解の向上 最新のAIエディタは、単一ファイルではなくプロジェクト全体のコンテキストを理解し、一貫性のあるコード提案を行います。これにより、Salesforceの複雑なオブジェクト関係やビジネスプロセスを考慮した開発が可能になります。

リアルタイムコード検証 コーディング中にSalesforceのガバナーリミットやセキュリティルールをチェックし、問題のあるコードパターンを事前に警告します。これにより、デバッグ時間の大幅短縮が実現できます。

自動テストケース生成 Salesforceでは高いテストカバレッジが求められますが、AIエディタは機能的なテストケースを自動生成し、テスト品質の向上と開発時間の短縮を両立させます。

コード品質向上への貢献

ベストプラクティスの自動適用 AIエディタは、Salesforce開発のベストプラクティス（トリガーパターン、バルク処理、エラーハンドリングなど）を自動的に適用したコードを提案します。経験の浅い開発者でも、高品質なコードを作成できるようになります。

セキュリティ強化 CRUD権限チェック、SOQL インジェクション対策、適切な共有設定など、セキュリティに関する考慮事項を自動的に組み込んだコードを生成します。

保守性の向上 可読性が高く、拡張しやすいコード構造を提案することで、長期的な保守性を向上させます。また、適切なコメントやドキュメンテーションも自動生成されます。

以下のようなコードとコメントが自動生成されるためSalesforce特有の書き方（sObjectの操作、SOQL埋め込み、ガバナーリミット対応など）を自然に習得することができます。

実践的なVibe Coding手法

AIエディタを活用した具体的な開発フロー

ステップ1: 要件の自然言語化

従来の詳細設計書の代わりに、実現したい機能を自然言語で記述します。この段階では、技術的な詳細よりもビジネス価値に焦点を当てます。

例：「顧客からの問い合わせメールを受信したときに、自動的にケースを作成し、
適切な担当者にアサインし、顧客に自動返信を送信する機能を実装したい」

ステップ2: AIとの対話による要件精緻化

AIエディタとの対話を通じて、曖昧な要件を具体的な技術要件に変換します。

開発者: "メール受信時の自動ケース作成機能を実装したい"
AI: "Email-to-Caseの機能実装ですね。以下の要素が必要です：
1. インバウンドメール処理のApexクラス
2. ケース作成とアサインメントロジック
3. 自動返信のEmailテンプレート
4. エラーハンドリングとログ機能

どの部分から開始しますか？"

ステップ3: 段階的な実装

AIの提案に基づいて、機能を小さな単位に分割して段階的に実装します。

// ステップ3-1: 基本的なメール処理クラス
global class EmailToCaseHandler implements Messaging.InboundEmailHandler {
    global Messaging.InboundEmailResult handleInboundEmail(
        Messaging.InboundEmail email, 
        Messaging.InboundEnvelope envelope
    ) {
        Messaging.InboundEmailResult result = new Messaging.InboundEmailResult();
        
        try {
            Case newCase = createCaseFromEmail(email);
            assignCaseToAgent(newCase);
            sendAutoReply(email.fromAddress, newCase.CaseNumber);
            result.success = true;
        } catch (Exception e) {
            logError(e, email);
            result.success = false;
        }
        
        return result;
    }
}

ステップ4: AIによる継続的改善

実装したコードをAIがレビューし、改善提案を行います。

// AIが提案する改善版
global class EmailToCaseHandler implements Messaging.InboundEmailHandler {
    // 設定値の外部化
    private static final EmailToCaseSettings__c settings = EmailToCaseSettings__c.getInstance();
    
    global Messaging.InboundEmailResult handleInboundEmail(
        Messaging.InboundEmail email, 
        Messaging.InboundEnvelope envelope
    ) {
        Messaging.InboundEmailResult result = new Messaging.InboundEmailResult();
        
        try {
            // バリデーション追加
            if (!isValidEmail(email)) {
                throw new EmailValidationException('Invalid email format');
            }
            
            Case newCase = createCaseFromEmail(email);
            assignCaseToAgent(newCase);
            
            // 非同期での自動返信（ガバナーリミット対策）
            System.enqueueJob(new AutoReplyQueueable(email.fromAddress, newCase.CaseNumber));
            
            result.success = true;
        } catch (Exception e) {
            logError(e, email);
            result.success = false;
            result.message = 'Error processing email: ' + e.getMessage();
        }
        
        return result;
    }
}

プロンプトエンジニアリングのコツ

効果的なプロンプトの構造

1. コンテキストの明確化

"Salesforceの本番環境で使用する、エンタープライズレベルのApexトリガーを作成してください。
ガバナーリミットとセキュリティを考慮した実装が必要です。"

2. 具体的な制約条件の提示

"以下の制約を満たすLightning Web Componentを作成してください：
- 10,000件以上のレコードを効率的に表示
- モバイル対応（レスポンシブデザイン）
- Lightning Design Systemに準拠
- アクセシビリティ要件（WCAG 2.1 AA）を満たす"

3. 期待する出力形式の指定

"以下の形式でコードを生成してください：
1. クラス全体のコード
2. 重要な部分の解説コメント
3. 使用方法の例
4. テストクラスの実装
5. 注意点とベストプラクティス"

反復的改善のためのプロンプト例

"先ほど生成したApexクラスを以下の観点で改善してください：
1. パフォーマンス最適化（特にSOQL実行回数の削減）
2. エラーハンドリングの強化
3. ログ出力の改善
4. コードの可読性向上
5. 単体テストカバレッジの向上"

ベストプラクティス

1. 段階的な開発アプローチ 一度に完璧なコードを求めるのではなく、動作する最小限の実装から始めて、段階的に機能を追加していきます。

2. AIの提案の検証 AIが生成したコードは必ず動作確認を行い、Salesforceの制約やセキュリティ要件を満たしているかチェックします。

3. チーム知識の共有 効果的だったプロンプトや手法は、チーム内で共有し、組織全体のVibe Coding能力を向上させます。

4. 継続的学習 AIエディタの新機能や改善されたプロンプト技術を継続的に学習し、開発手法をアップデートしていきます。

Salesofrceの開発に関するユースケース

参考

AIエディタを使ったVibe codingの実際の開発事例（ユースケース）

ここで挙げた事例を実際に手を動かして進める手順は、AIエディタを使った Vibe…

続きを読む

まとめ

Vibe Codingがもたらす開発パラダイムの変化

AIエディタを活用したVibe Codingは、Salesforce開発において従来の課題を大幅に解決し、新しい開発体験を提供しています。詳細な設計書に依存した開発から、直感的で創造的な開発へのシフトが可能になり、開発者はより高次元のビジネス価値創出に集中できるようになります。

技術トレンドとの統合

ローコード・ノーコード開発との融合 AIエディタによるVibe Codingは、Salesforceのローコード・ノーコード機能と相互補完的な関係にあります。Flow Builder、Process Builder、Lightning App Builderなどの宣言的開発ツールとAIエディタを組み合わせることで、より柔軟で強力な開発環境が実現できます。

DevOpsとの統合 CI/CDパイプライン、自動テスト、デプロイメント自動化などのDevOpsプラクティスとAIエディタを統合することで、コード生成から本番環境への展開まで一貫した自動化が可能になります。

アジャイル開発手法との親和性 Vibe Codingの反復的で柔軟なアプローチは、アジャイル開発やスクラム手法と非常に相性が良く、スプリント内での迅速な機能開発と改善が可能になります。

続き

本記事では、AIエディタやVibe codingについての用語や概念について説明してきました。AIエディタの種類やそれぞれの特徴についても理解いただけたと思います。

環境構築については、別の記事で紹介したいと思います。

サポーターさん

実際に環境を構築して、AIエディタを利用できるようにしていきましょう。

関連記事

AIエディタを使ったVibe codingの実際の開発事例（ユースケース）

Lightning Web Componentの開発例

要件：顧客管理ダッシュボードの作成

自然言語での要求：

"取引先の情報を表示し、関連する商談と取引先責任者を
タブ形式で切り替えて表示できるダッシュボードコンポーネントを作成したい。
リアルタイムでデータを更新し、Excel出力機能も必要。"

AIエディタによる段階的実装

ステップ1: 基本構造の生成

<!-- accountDashboard.html -->
<template>
    <lightning-card title="顧客管理ダッシュボード" icon-name="standard:account">
        <div slot="actions">
            <lightning-button 
                label="Excel出力" 
                onclick={exportToExcel}
                variant="brand">
            </lightning-button>
        </div>
        
        <lightning-tabset>
            <lightning-tab label="取引先情報" value="account">
                <c-account-detail account-id={accountId}></c-account-detail>
            </lightning-tab>
            
            <lightning-tab label="商談" value="opportunities">
                <c-opportunity-list account-id={accountId}></c-opportunity-list>
            </lightning-tab>
            
            <lightning-tab label="取引先責任者" value="contacts">
                <c-contact-list account-id={accountId}></c-contact-list>
            </lightning-tab>
        </lightning-tabset>
    </lightning-card>
</template>

ステップ2: JavaScriptコントローラーの実装

// accountDashboard.js
import { LightningElement, api, wire, track } from 'lwc';
import { refreshApex } from '@salesforce/apex';
import getAccountData from '@salesforce/apex/AccountDashboardController.getAccountData';
import exportAccountData from '@salesforce/apex/AccountDashboardController.exportAccountData';
import { ShowToastEvent } from 'lightning/platformShowToastEvent';

export default class AccountDashboard extends LightningElement {
    @api accountId;
    @track accountData;
    wiredAccountData;

    @wire(getAccountData, { accountId: '$accountId' })
    wireAccountData(result) {
        this.wiredAccountData = result;
        if (result.data) {
            this.accountData = result.data;
        } else if (result.error) {
            this.showToast('エラー', result.error.body.message, 'error');
        }
    }

    async handleRefresh() {
        try {
            await refreshApex(this.wiredAccountData);
            this.showToast('成功', 'データが更新されました', 'success');
        } catch (error) {
            this.showToast('エラー', 'データの更新に失敗しました', 'error');
        }
    }

    async exportToExcel() {
        try {
            const result = await exportAccountData({ accountId: this.accountId });
            // ファイルダウンロード処理
            const link = document.createElement('a');
            link.href = 'data:application/vnd.ms-excel;base64,' + result;
            link.download = `account_${this.accountId}_data.xlsx`;
            link.click();
            
            this.showToast('成功', 'Excelファイルをダウンロードしました', 'success');
        } catch (error) {
            this.showToast('エラー', 'Excel出力に失敗しました', 'error');
        }
    }

    showToast(title, message, variant) {
        this.dispatchEvent(new ShowToastEvent({
            title: title,
            message: message,
            variant: variant
        }));
    }
}

ステップ3: Apexコントローラーの実装

public with sharing class AccountDashboardController {
    
    @AuraEnabled(cacheable=true)
    public static AccountDataWrapper getAccountData(Id accountId) {
        try {
            if (!Schema.sObjectType.Account.isAccessible()) {
                throw new AuraHandledException('取引先への読み取り権限がありません');
            }

            Account account = [
                SELECT Id, Name, BillingAddress, Phone, Website, 
                       AnnualRevenue, NumberOfEmployees, Industry
                FROM Account 
                WHERE Id = :accountId 
                LIMIT 1
            ];

            List<Opportunity> opportunities = [
                SELECT Id, Name, StageName, Amount, CloseDate
                FROM Opportunity 
                WHERE AccountId = :accountId 
                ORDER BY CloseDate DESC
                LIMIT 10
            ];

            List<Contact> contacts = [
                SELECT Id, Name, Email, Phone, Title
                FROM Contact 
                WHERE AccountId = :accountId 
                ORDER BY LastModifiedDate DESC
                LIMIT 20
            ];

            return new AccountDataWrapper(account, opportunities, contacts);
            
        } catch (Exception e) {
            throw new AuraHandledException('データの取得に失敗しました: ' + e.getMessage());
        }
    }

    @AuraEnabled
    public static String exportAccountData(Id accountId) {
        try {
            AccountDataWrapper data = getAccountData(accountId);
            
            // Excel生成ロジック（簡略化）
            String csvData = generateCSVData(data);
            return EncodingUtil.base64Encode(Blob.valueOf(csvData));
            
        } catch (Exception e) {
            throw new AuraHandledException('Excel出力に失敗しました: ' + e.getMessage());
        }
    }

    private static String generateCSVData(AccountDataWrapper data) {
        List<String> csvLines = new List<String>();
        
        // ヘッダー
        csvLines.add('タイプ,名前,ステージ/タイトル,金額/メール,完了日/電話');
        
        // 取引先データ
        csvLines.add(String.format('取引先,{0},{1},{2},{3}', 
            new String[]{
                data.account.Name,
                data.account.Industry,
                String.valueOf(data.account.AnnualRevenue),
                data.account.Phone
            }));
        
        // 商談データ
        for (Opportunity opp : data.opportunities) {
            csvLines.add(String.format('商談,{0},{1},{2},{3}', 
                new String[]{
                    opp.Name,
                    opp.StageName,
                    String.valueOf(opp.Amount),
                    String.valueOf(opp.CloseDate)
                }));
        }
        
        return String.join(csvLines, 'n');
    }

    public class AccountDataWrapper {
        @AuraEnabled public Account account { get; set; }
        @AuraEnabled public List<Opportunity> opportunities { get; set; }
        @AuraEnabled public List<Contact> contacts { get; set; }
        
        public AccountDataWrapper(Account acc, List<Opportunity> opps, List<Contact> cons) {
            this.account = acc;
            this.opportunities = opps;
            this.contacts = cons;
        }
    }
}

Apex クラスの実装例

要件：複雑な承認プロセスの自動化

自然言語での要求：

"商談の金額に応じて、異なる承認者ルートを自動設定し、
承認状況をリアルタイムで追跡できるシステムを実装したい。
承認者の不在時は代理承認者に自動エスカレーションする機能も必要。"

AIエディタによる実装

public class OpportunityApprovalManager {
    
    // 承認ルール設定
    private static final Map<Decimal, String> APPROVAL_RULES = new Map<Decimal, String>{
        100000 => 'MANAGER_APPROVAL',
        500000 => 'DIRECTOR_APPROVAL',
        1000000 => 'VP_APPROVAL',
        5000000 => 'EXECUTIVE_APPROVAL'
    };
    
    @InvocableMethod(label='承認プロセス開始')
    public static List<ApprovalResult> initiateApprovalProcess(List<ApprovalRequest> requests) {
        List<ApprovalResult> results = new List<ApprovalResult>();
        
        for (ApprovalRequest request : requests) {
            try {
                ApprovalResult result = processOpportunityApproval(request.opportunityId);
                results.add(result);
            } catch (Exception e) {
                ApprovalResult errorResult = new ApprovalResult();
                errorResult.success = false;
                errorResult.message = 'エラー: ' + e.getMessage();
                errorResult.opportunityId = request.opportunityId;
                results.add(errorResult);
            }
        }
        
        return results;
    }
    
    private static ApprovalResult processOpportunityApproval(Id opportunityId) {
        // 商談データの取得
        Opportunity opp = [
            SELECT Id, Name, Amount, OwnerId, StageName, Account.OwnerId
            FROM Opportunity 
            WHERE Id = :opportunityId 
            LIMIT 1
        ];
        
        // 承認レベルの決定
        String approvalLevel = determineApprovalLevel(opp.Amount);
        
        // 承認者の特定
        List<Id> approvers = getApprovers(opp, approvalLevel);
        
        // 承認プロセスの作成
        Approval.ProcessSubmitRequest req = new Approval.ProcessSubmitRequest();
        req.setComments('システムによる自動承認申請');
        req.setObjectId(opportunityId);
        req.setSubmitterId(UserInfo.getUserId());
        req.setProcessDefinitionNameOrId('OpportunityApprovalProcess');
        req.setSkipEntryCriteria(false);
        
        // 承認申請の実行
        Approval.ProcessResult result = Approval.process(req);
        
        // 結果の作成
        ApprovalResult approvalResult = new ApprovalResult();
        approvalResult.success = result.isSuccess();
        approvalResult.opportunityId = opportunityId;
        approvalResult.processInstanceId = result.getInstanceId();
        approvalResult.message = result.isSuccess() ? 
            '承認プロセスが開始されました' : 
            '承認プロセスの開始に失敗しました: ' + String.join(result.getErrors(), ', ');
        
        // 承認状況の追跡レコード作成
        createApprovalTracking(opp, approvers, result.getInstanceId());
        
        return approvalResult;
    }
    
    private static String determineApprovalLevel(Decimal amount) {
        if (amount == null) return 'MANAGER_APPROVAL';
        
        List<Decimal> thresholds = new List<Decimal>(APPROVAL_RULES.keySet());
        thresholds.sort();
        
        for (Decimal threshold : thresholds) {
            if (amount <= threshold) {
                return APPROVAL_RULES.get(threshold);
            }
        }
        
        return 'EXECUTIVE_APPROVAL';
    }
    
    private static List<Id> getApprovers(Opportunity opp, String approvalLevel) {
        List<Id> approvers = new List<Id>();
        
        // ユーザーの役職情報を取得
        User owner = [
            SELECT Id, ManagerId, UserRole.Name, Department
            FROM User 
            WHERE Id = :opp.OwnerId 
            LIMIT 1
        ];
        
        switch on approvalLevel {
            when 'MANAGER_APPROVAL' {
                if (owner.ManagerId != null) {
                    approvers.add(owner.ManagerId);
                }
            }
            when 'DIRECTOR_APPROVAL' {
                // 部門ディレクターを検索
                List<User> directors = [
                    SELECT Id FROM User 
                    WHERE UserRole.Name LIKE '%Director%' 
                    AND Department = :owner.Department 
                    AND IsActive = true
                    LIMIT 3
                ];
                for (User director : directors) {
                    approvers.add(director.Id);
                }
            }
            when 'VP_APPROVAL' {
                // VP以上の役職者を検索
                List<User> vps = [
                    SELECT Id FROM User 
                    WHERE (UserRole.Name LIKE '%VP%' OR UserRole.Name LIKE '%Vice President%')
                    AND IsActive = true
                    LIMIT 5
                ];
                for (User vp : vps) {
                    approvers.add(vp.Id);
                }
            }
            when 'EXECUTIVE_APPROVAL' {
                // 役員クラスを検索
                List<User> executives = [
                    SELECT Id FROM User 
                    WHERE UserRole.Name LIKE '%Executive%' 
                    OR UserRole.Name LIKE '%CEO%'
                    OR UserRole.Name LIKE '%President%'
                    AND IsActive = true
                    LIMIT 5
                ];
                for (User exec : executives) {
                    approvers.add(exec.Id);
                }
            }
        }
        
        return approvers;
    }
    
    private static void createApprovalTracking(Opportunity opp, List<Id> approvers, Id processInstanceId) {
        List<ApprovalTracking__c> trackingRecords = new List<ApprovalTracking__c>();
        
        for (Id approverId : approvers) {
            ApprovalTracking__c tracking = new ApprovalTracking__c();
            tracking.Opportunity__c = opp.Id;
            tracking.Approver__c = approverId;
            tracking.ProcessInstanceId__c = processInstanceId;
            tracking.Status__c = 'Pending';
            tracking.CreatedDate__c = System.now();
            trackingRecords.add(tracking);
        }
        
        if (!trackingRecords.isEmpty()) {
            insert trackingRecords;
        }
    }
    
    // 代理承認者への自動エスカレーション
    @future
    public static void checkForEscalation(Set<Id> processInstanceIds) {
        List<ProcessInstance> processes = [
            SELECT Id, Status, CreatedDate, TargetObjectId
            FROM ProcessInstance 
            WHERE Id IN :processInstanceIds
            AND Status = 'Pending'
        ];
        
        for (ProcessInstance process : processes) {
            // 24時間経過した場合のエスカレーション
            if (process.CreatedDate.addHours(24) < System.now()) {
                escalateToDelegate(process.Id);
            }
        }
    }
    
    private static void escalateToDelegate(Id processInstanceId) {
        // 現在の承認者を取得
        List<ProcessInstanceWorkitem> workitems = [
            SELECT Id, ActorId, ProcessInstanceId
            FROM ProcessInstanceWorkitem 
            WHERE ProcessInstanceId = :processInstanceId
        ];
        
        for (ProcessInstanceWorkitem workitem : workitems) {
            // 代理承認者を検索
            List<User> delegates = [
                SELECT Id FROM User 
                WHERE ManagerId = :workitem.ActorId 
                AND IsActive = true
                LIMIT 1
            ];
            
            if (!delegates.isEmpty()) {
                // 代理承認者に再アサイン
                Approval.ProcessWorkitemRequest req = new Approval.ProcessWorkitemRequest();
                req.setComments('自動エスカレーション: 代理承認者へのアサイン');
                req.setAction('Reassign');
                req.setWorkitemId(workitem.Id);
                req.setNewActorIds(new List<Id>{delegates[0].Id});
                
                Approval.process(req);
            }
        }
    }
    
    // データクラス
    public class ApprovalRequest {
        @InvocableVariable(required=true)
        public Id opportunityId;
    }
    
    public class ApprovalResult {
        @InvocableVariable
        public Boolean success;
        @InvocableVariable
        public String message;
        @InvocableVariable
        public Id opportunityId;
        @InvocableVariable
        public Id processInstanceId;
    }
}

テストコードの自動生成

AIエディタによるテストクラスの生成

@isTest
public class OpportunityApprovalManagerTest {
    
    @TestSetup
    static void setupTestData() {
        // テスト用のユーザー作成
        Profile profile = [SELECT Id FROM Profile WHERE Name = 'Standard User' LIMIT 1];
        
        User manager = new User(
            FirstName = 'Test',
            LastName = 'Manager',
            Email = 'testmanager@example.com',
            Username = 'testmanager@example.com.test',
            Alias = 'tmgr',
            ProfileId = profile.Id,
            TimeZoneSidKey = 'Asia/Tokyo',
            LocaleSidKey = 'ja_JP',
            EmailEncodingKey = 'UTF-8',
            LanguageLocaleKey = 'ja'
        );
        insert manager;
        
        User salesUser = new User(
            FirstName = 'Test',
            LastName = 'Sales',
            Email = 'testsales@example.com',
            Username = 'testsales@example.com.test',
            Alias = 'tsales',
            ProfileId = profile.Id,
            ManagerId = manager.Id,
            TimeZoneSidKey = 'Asia/Tokyo',
            LocaleSidKey = 'ja_JP',
            EmailEncodingKey = 'UTF-8',
            LanguageLocaleKey = 'ja'
        );
        insert salesUser;
        
        // テスト用の取引先作成
        Account testAccount = new Account(
            Name = 'テスト取引先',
            OwnerId = salesUser.Id
        );
        insert testAccount;
        
        // テスト用の商談作成
        List<Opportunity> opportunities = new List<Opportunity>();
        
        // 小額商談（マネージャー承認）
        opportunities.add(new Opportunity(
            Name = 'テスト商談 - 小額',
            AccountId = testAccount.Id,
            Amount = 50000,
            CloseDate = Date.today().addDays(30),
            StageName = 'Prospecting',
            OwnerId = salesUser.Id
        ));
        
        // 中額商談（ディレクター承認）
        opportunities.add(new Opportunity(
            Name = 'テスト商談 - 中額',
            AccountId = testAccount.Id,
            Amount = 300000,
            CloseDate = Date.today().addDays(30),
            StageName = 'Prospecting',
            OwnerId = salesUser.Id
        ));
        
        // 高額商談（VP承認）
        opportunities.add(new Opportunity(
            Name = 'テスト商談 - 高額',
            AccountId = testAccount.Id,
            Amount = 800000,
            CloseDate = Date.today().addDays(30),
            StageName = 'Prospecting',
            OwnerId = salesUser.Id
        ));
        
        insert opportunities;
    }
    
    @isTest
    static void testManagerApprovalProcess() {
        Opportunity smallOpp = [
            SELECT Id FROM Opportunity 
            WHERE Name = 'テスト商談 - 小額' 
            LIMIT 1
        ];
        
        Test.startTest();
        
        List<OpportunityApprovalManager.ApprovalRequest> requests = 
            new List<OpportunityApprovalManager.ApprovalRequest>();
        OpportunityApprovalManager.ApprovalRequest request = 
            new OpportunityApprovalManager.ApprovalRequest();
        request.opportunityId = smallOpp.Id;
        requests.add(request);
        
        List<OpportunityApprovalManager.ApprovalResult> results = 
            OpportunityApprovalManager.initiateApprovalProcess(requests);
        
        Test.stopTest();
        
        // 結果の検証
        System.assertEquals(1, results.size(), '結果が1件返されること');
        System.assertEquals(true, results[0].success, '承認プロセスが成功すること');
        System.assertEquals(smallOpp.Id, results[0].opportunityId, '商談IDが正しく設定されること');
        
        // 追跡レコードの確認
        List<ApprovalTracking__c> trackings = [
            SELECT Id, Status__c 
            FROM ApprovalTracking__c 
            WHERE Opportunity__c = :smallOpp.Id
        ];
        System.assertNotEquals(0, trackings.size(), '追跡レコードが作成されること');
    }
    
    @isTest
    static void testDirectorApprovalProcess() {
        Opportunity mediumOpp = [
            SELECT Id FROM Opportunity 
            WHERE Name = 'テスト商談 - 中額' 
            LIMIT 1
        ];
        
        Test.startTest();
        
        List<OpportunityApprovalManager.ApprovalRequest> requests = 
            new List<OpportunityApprovalManager.ApprovalRequest>();
        OpportunityApprovalManager.ApprovalRequest request = 
            new OpportunityApprovalManager.ApprovalRequest();
        request.opportunityId = mediumOpp.Id;
        requests.add(request);
        
        List<OpportunityApprovalManager.ApprovalResult> results = 
            OpportunityApprovalManager.initiateApprovalProcess(requests);
        
        Test.stopTest();
        
        // 結果の検証
        System.assertEquals(1, results.size(), '結果が1件返されること');
        System.assertEquals(mediumOpp.Id, results[0].opportunityId, '商談IDが正しく設定されること');
    }
    
    @isTest
    static void testVPApprovalProcess() {
        Opportunity largeOpp = [
            SELECT Id FROM Opportunity 
            WHERE Name = 'テスト商談 - 高額' 
            LIMIT 1
        ];
        
        Test.startTest();
        
        List<OpportunityApprovalManager.ApprovalRequest> requests = 
            new List<OpportunityApprovalManager.ApprovalRequest>();
        OpportunityApprovalManager.ApprovalRequest request = 
            new OpportunityApprovalManager.ApprovalRequest();
        request.opportunityId = largeOpp.Id;
        requests.add(request);
        
        List<OpportunityApprovalManager.ApprovalResult> results = 
            OpportunityApprovalManager.initiateApprovalProcess(requests);
        
        Test.stopTest();
        
        // 結果の検証
        System.assertEquals(1, results.size(), '結果が1件返されること');
        System.assertEquals(largeOpp.Id, results[0].opportunityId, '商談IDが正しく設定されること');
    }
    
    @isTest
    static void testErrorHandling() {
        Test.startTest();
        
        List<OpportunityApprovalManager.ApprovalRequest> requests = 
            new List<OpportunityApprovalManager.ApprovalRequest>();
        OpportunityApprovalManager.ApprovalRequest request = 
            new OpportunityApprovalManager.ApprovalRequest();
        request.opportunityId = null; // 不正なID
        requests.add(request);
        
        List<OpportunityApprovalManager.ApprovalResult> results = 
            OpportunityApprovalManager.initiateApprovalProcess(requests);
        
        Test.stopTest();
        
        // エラーハンドリングの検証
        System.assertEquals(1, results.size(), '結果が1件返されること');
        System.assertEquals(false, results[0].success, 'エラーが正しく処理されること');
        System.assert(results[0].message.contains('エラー'), 'エラーメッセージが設定されること');
    }
    
    @isTest
    static void testBulkProcessing() {
        List<Opportunity> allOpps = [SELECT Id FROM Opportunity];
        
        Test.startTest();
        
        List<OpportunityApprovalManager.ApprovalRequest> requests = 
            new List<OpportunityApprovalManager.ApprovalRequest>();
        
        for (Opportunity opp : allOpps) {
            OpportunityApprovalManager.ApprovalRequest request = 
                new OpportunityApprovalManager.ApprovalRequest();
            request.opportunityId = opp.Id;
            requests.add(request);
        }
        
        List<OpportunityApprovalManager.ApprovalResult> results = 
            OpportunityApprovalManager.initiateApprovalProcess(requests);
        
        Test.stopTest();
        
        // バルク処理の検証
        System.assertEquals(allOpps.size(), results.size(), '全ての商談が処理されること');
        
        for (OpportunityApprovalManager.ApprovalResult result : results) {
            System.assertNotEquals(null, result.opportunityId, '商談IDが設定されること');
        }
    }
}

6. 注意点と課題

セキュリティ考慮事項

AIエディタ使用時のセキュリティリスク

1. 機密情報の漏洩リスク AIエディタにコードを送信する際、顧客情報や機密データが含まれる可能性があります。以下の対策が必要です：

• 実際の顧客データを含むコードをAIエディタに送信しない
• テストデータやサンプルデータを使用してコード生成を行う
• 社内のデータ分類ポリシーに従った利用ガイドラインの策定
• AIエディタの利用ログの監査と定期的なレビュー

2. 生成されたコードのセキュリティ脆弱性 AIが生成したコードには、セキュリティ上の問題が含まれる可能性があります：

// 危険な例：SQLインジェクション脆弱性
public static List<Account> searchAccounts(String searchTerm) {
    // AIが生成した危険なコード例
    String query = 'SELECT Id, Name FROM Account WHERE Name LIKE '%' + searchTerm + '%'';
    return Database.query(query); // SQLインジェクション脆弱性
}

// 安全な実装例
public static List<Account> searchAccountsSafe(String searchTerm) {
    String safeSearchTerm = '%' + String.escapeSingleQuotes(searchTerm) + '%';
    return [SELECT Id, Name FROM Account WHERE Name LIKE :safeSearchTerm];
}

3. 権限とアクセス制御 AIが生成するコードが適切な権限チェックを含んでいるか確認が必要です：

// 権限チェックを含む安全なコード例
public static List<Account> getAccounts() {
    // オブジェクトレベルの権限チェック
    if (!Schema.sObjectType.Account.isAccessible()) {
        throw new AuraHandledException('取引先への読み取り権限がありません');
    }
    
    // フィールドレベルの権限チェック
    if (!Schema.sObjectType.Account.fields.Name.isAccessible()) {
        throw new AuraHandledException('取引先名フィールドへの読み取り権限がありません');
    }
    
    return [SELECT Id, Name FROM Account WITH SECURITY_ENFORCED LIMIT 100];
}

コード品質の担保方法

1. AIによるコード生成後の必須チェック項目

Salesforce固有の制約チェック

• ガバナーリミット（SOQL実行回数、DML操作回数、ヒープサイズなど）への対応
• バルク処理の実装
• 適切な例外処理の実装
• トランザクション管理の考慮

// 良い例：ガバナーリミットを考慮したコード
public class ContactProcessor {
    public static void processContacts(List<Contact> contacts) {
        List<Contact> contactsToUpdate = new List<Contact>();
        
        // バルク処理でSOQL実行回数を最小化
        Map<Id, Account> accountMap = new Map<Id, Account>([
            SELECT Id, Industry 
            FROM Account 
            WHERE Id IN (SELECT AccountId FROM Contact WHERE Id IN :contacts)
        ]);
        
        for (Contact contact : contacts) {
            if (accountMap.containsKey(contact.AccountId)) {
                contact.Industry__c = accountMap.get(contact.AccountId).Industry;
                contactsToUpdate.add(contact);
            }
        }
        
        // バルクDML操作
        if (!contactsToUpdate.isEmpty()) {
            try {
                Database.update(contactsToUpdate, false);
            } catch (DmlException e) {
                System.debug('DML Error: ' + e.getMessage());
                // 適切なエラーハンドリング
            }
        }
    }
}

2. 静的コード解析ツールの活用

• PMD for Salesforce
• SonarQube Salesforce Plugin
• Salesforce Code Analyzer

3. コードレビュープロセスの強化 AIが生成したコードについては、特に以下の観点でのレビューを強化：

• ビジネスロジックの正確性
• パフォーマンスの最適化
• セキュリティ要件の満足
• 保守性とテスタビリティ

チーム開発での運用ポイント

1. AIエディタ利用のガイドライン策定

利用ルールの明文化

## AIエディタ利用ガイドライン

### 基本方針
1. 本番データを含むコードをAIエディタに送信しない
2. 生成されたコードは必ず動作確認とセキュリティチェックを行う
3. AIの提案をそのまま採用せず、チームの規約に合わせて調整する

### 利用可能な範囲
- ボイラープレートコードの生成
- テストコードの初期実装
- リファクタリングの提案
- ドキュメンテーションの作成

### 利用禁止事項
- 本番環境の機密データを含むコードの送信
- 未検証のコードの直接的な本番環境への適用
- ライセンスが不明なコードの利用

2. 品質基準の統一

コード品質チェックリスト

• Salesforceガバナーリミットへの対応
• 適切な例外処理の実装
• セキュリティ要件の満足
• テストカバレッジ75%以上
• コメントとドキュメンテーションの充実
• チームのコーディング規約への準拠

3. 知識共有とベストプラクティスの蓄積

効果的なプロンプトの共有 チーム内で効果的だったプロンプトや手法を共有し、組織全体のVibe Coding能力を向上させます。

## 有効なプロンプト例集

### Apexクラス生成
「Salesforceのガバナーリミットを考慮し、バルク処理に対応した
[機能名]のApexクラスを作成してください。エラーハンドリングと
ログ出力も含めて実装してください。」

### テストクラス生成
「先ほど作成したApexクラスに対して、以下の条件を満たす
テストクラスを作成してください：
- 正常系・異常系の両方をテスト
- バルク処理のテスト
- 75%以上のカバレッジ確保」

4. 継続的な改善プロセス

定期的な振り返り

• 月次でのAIエディタ利用状況のレビュー
• 問題点や改善点の特定と対策の検討
• 新機能や新しい手法の評価と導入検討

メトリクスの計測

• 開発速度の向上度
• コード品質の指標（バグ発生率、レビュー指摘事項数）
• 開発者の満足度
• 学習コストの変化

関連記事