生成AI導入ガイド

最初に書くのは、誰の、どの業務の、どの出力を変えるかです。「営業を効率化する」では粗すぎて、合否を判定できません。「問い合わせフォームへの一次返信を、担当者が送る前の下書きとして作る」のように、入力・出力・受け取る人・最終的に使う人が分かる粒度まで絞ります。対象は、効果を測りやすい1つの業務から始めます。

次に、その業務の現在値をベースラインとして記録します。1件あたりの処理時間、修正や差し戻しの頻度、回答までの待ち時間、月あたりの件数など、導入後にも同じ方法で測れる値を選びます。現在値を測っていなければ、AIを入れる前に測ります。ベースラインがないまま導入すると、「使われている」ことは分かっても「良くなった」かは説明できません。

候補の業務が複数あり、どれから始めるか決まっていない段階なら、業務ごとの適用可否と優先順位を先に整理します。その進め方はAI導入診断の進め方に分けています。

Roleは、その担当がどの仕事をし、どこまでの権限を持つかです。Runtimeは、その仕事を実際に実行するモデル、製品、提供元です。「このAI製品が担当者」と両者をまとめて決めると、その製品の混雑や利用上限への到達といった事情で、業務そのものが止まります。

Netsujoの開発運用でも、役割を特定の製品に固定していた時期に、利用枠や同時実行枠の都合で作業が止まる問題が起きました。現在は役割と権限を先に定義し、必要な能力、渡してよい権限、利用枠の残り、その時点で実際に処理できるかを見てRuntimeを選んでいます。あるRuntimeが使えないときも、独立レビューが必要という条件は外しません。

企業の導入でも、API、既存のSaaS、自社向けに調整したモデルは、成熟度の段階として並べずに、運用契約の条件に合うかで選びます。判断材料は、扱うデータに対する利用条件、必要な能力、既存システムとの連携、費用、利用上限です。最新・最上位のモデルを使うことや自社専用のモデルを持つことは、それ自体を目標にしません。特定モデルの比較や順位付けは、変化が速く業務条件にも左右されるため扱いません。

NetsujoがChatGPT・Claude Code・Codexの分業開発で使っている割り当て方は、Roleごとの権限、作業の単位、受入条件の3つを先に決め、Runtimeを後から当てるものです。

「導入完了」は一つの状態ではありません。Netsujoの開発運用では、次の5つを別の状態として記録し、それぞれ別の証拠で確認しています。状態名はNetsujoの運用上の定義で、業界の規格ではありません。右の列は、企業のAI導入に置き換えた場合の読み方です。独立レビューは実装済みとマージ済みの間に置き、レビューした版とマージする版が同じかを確かめます。

独立レビューは、実装とは別のAssignmentと判定権限を持つレビュー担当が、実際に反映するものと同じ版を確認することです。使うRuntimeを変えるだけでは独立レビューになりません。レビューの後に内容が変わったら、古いレビュー結果を新しい版へ流用せず、確認し直します。作った人や同じAssignmentが自分の成果物のレビューを兼ねると、独立レビューになりません。

デプロイの成功が示すのは、反映の操作が最後まで走ったことです。利用者の環境で意図した変更が動いているかは、その変更でしか変わらない出力や画面を、本番で確かめて初めて分かります。SaaSの設定変更だけで導入する場合も、「設定の変更」「確認」「利用者への公開」「利用者の環境での確認」「業務で使ってよいという判断」を別々に記録すれば、同じ分け方が使えます。

レビューした版と反映した版の一致を確かめる方法はPR番号ではなくExact SHAで検証対象を固定する、本番の公開ドメインまで確認する方法はDeployが成功しても本番は未確認にあります。

利用者数、プロンプトの数、生成した文書や変更の数は、どれだけ使われたか、どれだけ作ったかを示します。事業成果の証拠にはなりません。Netsujo自身も、AIを使った開発で処理量が大きく増えた時期の記録を持っていますが、それを生産能力の証拠として扱い、プロダクトマーケットフィット・売上・継続の証拠とはしていません。その区別はPR数より「本番で検証済みになるまで」を測るとAIで会社は速くなった。経営者の時間は戻ったのかで扱っています。

測る時点は固定の月数で決めず、対象業務のサイクルとベースラインの取り方に合わせます。月次で締める業務なら締めの後、案件単位で進む業務なら一定の件数が終わった後というように、導入前と同じ単位で比べられる時点を選びます。

効果が出ないときは、ツールを入れ替える前に、AIの出力を受け取る側の業務の流れ、人の確認にかかる手間、ベースラインの測り方を見直します。