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

この記事では、設計工程で作る成果物を種類別に並べ、それぞれの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に任せ、人は打ち手を決めることに集中できます。

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

形骸化には、はっきりした理由が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にかなり任せられます。一方で、任せると見積もりが壊れる判定もはっきり存在します。この記事では、その境界線を含めて手順をまとめます。

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

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

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

この表が「目録」ではなく「見積もりの土台」になるのは、実現方法と難易度の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と相性がいいのか

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

業務のヒアリングメモ、既存システムの画面、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 評価版インストール手順はこちら →

この記事では、speedtest.jspで測定できる全9項目について、推奨値・判断基準・具体的な対策を解説します。

speedtest.jspとは — アクセス方法

speedtest.jspは、Salesforceが標準で提供するクライアントサイドの性能診断ツールです。設定メニューにはリンクがないため「隠れ機能」と呼ばれることもありますが、どのSalesforce組織でも利用できます。

アクセス方法： Salesforceにログインした状態で、URLを以下に書き換えるだけです。

https://[あなたのドメイン].lightning.force.com/speedtest.jsp

ページが開いたら「Test Speed」ボタンをクリックすると、数十秒で全項目の測定が完了します。

端末性能の指標 — Octane Score・Hardware Cores・Frame Rate

1. Octane Score — JavaScript実行性能

Google Octane 2.0 ベンチマークで、ブラウザのJavaScript実行速度を数値化したスコアです。

Lightning Experience（Salesforceの現行UI）はクライアント側のJavaScript処理に大きく依存しているため、この値がページの読み込み速度に直結します。Salesforce公式のTrailheadでも、Octane Scoreがパフォーマンスの最重要指標として紹介されています。

Salesforceは独自のパフォーマンス指標として EPT（Experience Page Time） を採用しており、ページの知覚的な読み込み完了時間を計測しています。Octane Scoreが低い端末では、このEPTが大幅に悪化します。AuraフレームワークからLWC（Lightning Web Components）への移行によりレンダリング効率が2〜60%改善された実績がありますが、それでもクライアント側のJS実行性能が基盤であることに変わりありません。

用語解説： 「ベンチマーク」とは、ハードウェアやソフトウェアの性能を統一基準で測定するテストのことです。Octane 2.0はGoogleが開発したJavaScriptベンチマークで、21種類のテストを実行してスコアを算出します。

補足： Octane 2.0は 2017年4月にGoogleが正式に非推奨（Retired）としています。 廃止の理由は「ブラウザベンダーがスコアを不正に最適化できる問題」と「現代のJavaScript利用パターンを反映していない」こと。後継ベンチマークとしてGoogleは Speedometer を推奨しています。ただし、Salesforceのspeedtest.jspでは現在もOctane Scoreを参考指標として採用しているため、Salesforce環境の診断においては依然として有用な指標です。

Salesforce公式ドキュメントによると、最低要件の環境では推奨スペックと比較してページロード時間が約50%遅くなるとされています。

対策： – ノートPCは電源に接続する（バッテリー駆動だと省電力モードでCPU速度が低下する） – 不要なブラウザ拡張機能を削除する（各拡張機能がJavaScriptリソースを消費する） – 他のアプリケーションを閉じてCPU/メモリリソースを確保する – VDI（仮想デスクトップ基盤）環境では、ユーザー密度の見直しやCPU世代の新しいサーバーへの移行が有効

2. Hardware Cores — CPUコア数

端末のCPUコア数（論理プロセッサ数）を表示します。

用語解説： 「コア」はCPU内部の処理ユニットです。コア数が多いほど同時に処理できるタスクが増えます。「論理プロセッサ」はHyper-Threadingなどの技術で1つの物理コアを2つに見せる仕組みです。8コアと表示されても、物理的には4コア+Hyper-Threadingの場合があります。

VDI環境では共有CPUにより実効コア数が少なくなるため、1セッションあたりの割当vCPU数をモニタリングすることが重要です。

3. Frame Rate — 描画性能

ブラウザのレンダリング性能をfps（frames per second：1秒あたりのフレーム数）で測定します。UIのアニメーション・ドラッグ操作・スクロールの滑らかさに影響します。

用語解説： 「fps」は映像の滑らかさを表す単位です。映画は24fps、一般的なモニターは60fpsで表示しています。Webアプリでは、60fpsを維持できていればユーザーはストレスを感じません。

対策： – ブラウザのGPUアクセラレーションが有効か確認する（Chrome: chrome://gpu にアクセス） – 重いVisualforceページやiframeの埋め込みを減らす – GPUが統合グラフィックス（Intel UHD Graphics等）の場合、ディスクリートGPU搭載機への更新を検討する

用語解説： 「GPUアクセラレーション」とは、通常CPUが行う画面描画処理をGPU（画像処理専用チップ）に委任して高速化する技術です。ブラウザの設定で無効になっていると、フレームレートが大幅に低下します。

ネットワーク性能の指標 — Latency・Download/Upload Speed

4. Latency — ネットワーク遅延

端末からSalesforceサーバーまでの往復遅延時間（RTT：Round Trip Time） です。ボタンクリックから画面が反応するまでの「もたつき」に直結します。

Salesforceの組織（Org）は、AP（アジア太平洋）、NA（北米）、EU（ヨーロッパ）などのインスタンスに紐づく物理データセンターでホストされています。ユーザーがデータセンターに近いほどレイテンシが低くなります。

用語解説： 「インスタンス」とは、Salesforceが世界各地に配置しているサーバー群の識別名です。AP26なら東京リージョン、NA135なら北米リージョンに配置されています。自分のOrgのインスタンスは「設定 > 組織情報」で確認できます。

対策： – VPN経由のアクセスでルーティングが遠回りになっていないか確認する – Salesforce CDNを活用して静的コンテンツの初回ロードを高速化する

用語解説： SalesforceはLightning Componentフレームワークの静的コンテンツ（JavaScript・CSS・画像等）の配信に Akamai CDN を使用しています。CDNにより、静的アセットがユーザーに最も近いエッジサーバーからキャッシュ配信されるため、初回ロードが高速化されます。なお、Experience Cloud（コミュニティサイト）はAkamai、Commerce CloudのLWRサイトはCloudflareと、製品ごとにCDNが使い分けられています。 – ネットワーク管理者に traceroute で経路を解析してもらう – 日本のユーザーが多い場合は、APxx（東京）インスタンスでの運用が理想

5. Download Speed — ダウンロード速度

Salesforceサーバーからのデータ受信速度です。ページの初回読み込み、レポート表示、ファイルダウンロードの体感速度に影響します。

用語解説： 「Mbps（メガビット毎秒）」はデータ転送速度の単位です。1 Mbpsなら1秒間に約125KBのデータを転送できます。5 Mbpsあれば、一般的なSalesforceの画面遷移はストレスなく行えます。

対策： – 社内LANの帯域やプロキシサーバーのボトルネックを確認する – 同一ネットワーク上の他のトラフィック（動画ストリーミング等）による帯域圧迫を排除する – Wi-Fiが不安定な場合は有線接続を試す – プロキシ/ファイアウォールでSalesforce関連ドメインがスロットリング（帯域制限）されていないか確認する

6. Upload Speed — アップロード速度

端末からSalesforceサーバーへのデータ送信速度です。レコード保存、ファイルアップロード、添付ファイル操作の体感速度に影響します。

対策はダウンロード速度と同様のネットワーク最適化が有効です。

サーバー・環境情報 — Your Server・Trust Status・User Agent

7. Your Server / Release — 接続先情報

接続先のSalesforceインスタンス名（例：AP26、NA135）と、適用されているSalesforceリリースバージョン（例：Spring ’26）を表示します。

活用方法： Orgのインスタンスが地理的に遠い場合、Salesforceサポートに相談してインスタンス移行を検討できます。日本のユーザーが大半なのにNAインスタンスに配置されている場合は、APインスタンスへの移行で大幅なレイテンシ改善が期待できます。

8. Trust Status — サービス稼働状況

Salesforce Trustサイトの情報と連携して、接続先インスタンスの稼働状況やメンテナンス情報を表示します。

2026年より My Trust Center が一般提供（GA）となり、各テナント固有のステータス情報がパーソナライズ表示されるようになりました。特定インスタンスや製品を選んでアラートメールを自己登録することも可能です。

活用方法： パフォーマンス低下時に、原因がSalesforce側のインフラ障害なのか自社環境なのかを切り分ける最初の確認ポイントになります。「遅い」と言われたらまずここを確認しましょう。

9. User Agent / WebGL — ブラウザ・GPU情報

ブラウザの種類・バージョン、OS情報、GPUの種類を表示します。

確認ポイント： – Salesforce公式が最もパフォーマンスが高いとするのはGoogle Chrome – GPUが統合グラフィックス（Intel UHD Graphics等）の場合、フレームレートがやや低めになる可能性がある

用語解説： 「WebGL」はブラウザ上で3Dグラフィックスを描画する技術で、GPUの種類と密接に関連します。「統合グラフィックス」はCPUに内蔵されたGPUで、独立GPU（NVIDIA GeForce等）と比べて描画性能が低い傾向があります。

総合推奨スペックまとめ

エンタープライズ環境で特に注意すべき2項目

エンタープライズ環境（特に金融系・官公庁系プロジェクト）では、以下の2項目がボトルネックになりやすいです。

1. VPN経由のレイテンシ セキュリティポリシーでVPN必須の環境では、VPNゲートウェイの物理的な位置によってレイテンシが大幅に増加します。東京→海外VPN→東京インスタンスという経路になると、100ms以下で済むはずの遅延が300ms以上になるケースもあります。

2. VDI環境のOctane Score VDI（仮想デスクトップ基盤）環境では、サーバーのCPUリソースを複数ユーザーで共有するため、Octane Scoreが物理PCの半分以下になることがあります。ユーザー密度（1台のサーバーに何人収容するか）の見直しが有効です。

用語解説： 「VDI（Virtual Desktop Infrastructure）」とは、サーバー上で仮想的なデスクトップ環境を動かし、端末からリモートで接続する仕組みです。セキュリティが強化される一方、CPUやメモリが共有されるため個々のユーザーのパフォーマンスが低下しやすい特徴があります。

Salesforceのパフォーマンス改善でお困りなら

speedtest.jspで問題箇所を特定できても、「VPN経路の最適化をどう進めるか」「VDI環境でのチューニングをどこから始めるか」は、環境ごとに事情が異なります。

AI開発実践ラボでは、Salesforce環境のパフォーマンス改善やLightning Experience最適化について、1on1のオンライントレーニングで実践的なノウハウをお伝えしています。

→ AI駆動開発トレーニング — 詳細を見る

まとめ

• speedtest.jsp はSalesforceの標準ツールで、URLを書き換えるだけでアクセスできる
• Octane Score 30,000以上・Latency 150ms以下・Download 3Mbps以上 が推奨ライン
• エンタープライズ環境では VPN経由のレイテンシ と VDI環境のOctane Score が課題になりやすい

パフォーマンス問題の切り分けの第一歩として、ぜひ活用してみてください。

関連リンク: – Salesforce Trailhead — Lightning Experienceパフォーマンス最適化 – Salesforce Trust — サービス稼働状況 – ポートフォリオ — AI汎用入力フォームLWC（LWCによるパフォーマンスを考慮したUI設計の実例）

Lightning Design System2のアイコン

• Lightning Design System2の公式サイトから以下のようなアイコンをダウンロード可能。
• 公式サイトはこちら

Data Cloud ダイアグラム・アイコン

• Data Cloudのアーキテクチャや設計で利用すると便利なアイコンやコンテナカード、ダイアグラムなどの素材が公式で提供されています。
• Salesforce公式のarchitectsサイト（こちら）を確認。LucidChartやGoogleスライド、PPTXなど複数の形式があります。

Canva

• CANVAは、デザイン経験がない人でも簡単にプロ品質のグラフィックを作成できるオンラインデザインツールです。AIを使った画像生成も可能
• 豊富なテンプレート、画像、フォントを使って、SNS投稿、プレゼンテーション、ポスター、名刺などを直感的な操作で制作できます。
• 無料版と有料版があり、個人からビジネスまで幅広く利用されています。ドラッグ&ドロップの簡単操作で、誰でも美しいデザインが作れる点が最大の特徴です。
• 公式サイトはこちら

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 codingの実際の開発事例（ユースケース） Li…

続きを読む

まとめ

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エディタを利用できるようにしていきましょう。

関連記事

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エディタ利用状況のレビュー
• 問題点や改善点の特定と対策の検討
• 新機能や新しい手法の評価と導入検討

メトリクスの計測

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

関連記事