本レポートは、2025年12月17日に開催したイベント「AIを“組み込む” ─ 大規模開発における推進と統制、現場の実情と次の一手」の内容を、前編・後編の2回構成でお届けしています。
前編では、AI活用を本格的に進めるにあたっての導入設計、ヒトとAIの役割分担の考え方について、現場の取り組みを中心に整理しました。（前編はこちら）
後編となる今回は、そうした取り組みを一部の現場にとどめず、組織全体へと広げていくフェーズに焦点を当てます。
ガバナンスやガードレールの設計、そして成果をどう捉え、どう説明していくのか。AI活用を継続的な取り組みにしていくための、より実践的な論点を見ていきます。
登壇者は、組織横断でAI活用を支援する KINTOテクノロジーズ の生成AIエバンジェリスト・和田氏、 印刷ECという巨大なシステムの現場でAIネイティブ化を進める ラクスル 事業 VPoE・箱崎。 モデレーターは ラクスル事業 CTO・岸野 が務めました。
Theme 2：ガバナンス／ガードレール設計
ルールの目的は「統制」ではなく「試せる状態を継続する」こと
ガバナンスの議論は、「縛る／縛らない」では終わりません。現場の自由が無くなると学習が止まり、統制が無くなると運用が破綻する。両者を同時に満たす設計が必要です。
ラクスル：基本は自由。ただし“推奨ライン”は提示する
ラクスルのスタンスは「まずはご自由にお試しください」。新しいツールやモデルも最初から強く制限しない。
ただし、本番開発では推奨ラインを提示し、日常的に使うツールは結果として2〜3パターンに収束していく。
自由の中に“収束圧”を自然に生む設計。
厳密に縛らないが、野放しにしない。この中間のバランスが現場の実務に耐える、という話でした。
KINTOテクノロジーズ：スピードと安全性を両輪で実現
KINTOテクノロジーズでは、AIファーストグループ、コーポレートIT、セキュリティ・プライバシーが密に連携してルールをつくる。 重要なのは「どちらが正しいか」ではなく、イノベーションとガバナンスが互いに支え合う構造を持つこと。
また、SaaSをレイヤー分けして運用する話は、明日から使える具体論でした。
- 入社初日から使える標準ツール
- 申請すれば使えるツール（上長承認不要）
- 申請＋上長承認が必要なツール
- 検証・研究用途のツール（未整理なものは厳しめに）
この区分があることで、現場から「これ使っていい？」が来たときに、“まず試せるプレイグラウンド”を提示できる。そしてツール側の進化で、気づけば標準ツールで事足りるケースも増える。
「AIだから特別扱いしない」— ルールが破綻しないための前提
このテーマの核心として語られたのは3つ。
- AIツールだから特別な審査フローをつくると、ほぼ確実に破綻する
- これからAIが含まれていないSaaSはほとんどなくなる
- AIも通常のSaaSと同じく「入力があって、出力がある」だけ
クリエイティブ系ツールの著作権リスクも、「AIだから起きる」のではなく、表現手段が変わっただけ。恒久的な“特別扱い”にしないことが重要だ、と。
この視点は、生成AI導入を「新ルール作り」から解放します。
むしろ、既存のSaaSガバナンスを“AI時代に耐える形へ再設計する”ことが本質だと気づかされました。
“迷っている呟き”を拾う。運用は大きな制度より先に、日々の応答から始まる
岸野が触れた「使っていいか分からず躊躇して終わる」問題に対し、和田氏は社内チャット（Times）の小さな投稿を例に挙げました。
- 「このツール使っていいんだっけ？」
- 「申請したら通るんでしたっけ？」
温度の低い呟きを見て見ぬふりをしない。誰かが反応し、そのやり取りを見た別の人が「聞いてみようかな」と思える。ガバナンスは制度設計だけでなく、“心理的ハードルを下げる運用”で広がっていく。この話は、現場感がありながら本質的でした。
“めんどくささ”は悪ではない。覚悟を問う最小のハードル
一方で、何でもノーチェックが理想かというと、そうではない。
箱崎は、最低限見るべき項目（運営主体、準拠法など）を挙げつつ、運用を軽くしすぎるとリスクが入り込むと語ります。
和田氏も「一定のめんどくささは必要」と同意します。それは「それでも使いたいですか？」という覚悟を問う最小の仕掛けであり、越えたからこそ“使い切る”姿勢が生まれる。ここがこのテーマの着地点でした。
最低限のハードルは設ける。ただし、そのハードルはできる限り越えやすく設計する。
Theme 3：メトリクス設計と説明責任
数字はゴールではなく「行動と空気を変えるための材料」
AI導入が進むほど、経営や周辺組織からの問いは変わります。
- 「で、何がどれだけ良くなったの？」
- 「生産性は上がった？」
- 「事業へのインパクトは？」
ここで“都合のいい数字”をつくると、いずれ破綻します。両社が選んだのは、AI特有の指標に寄せるのではなく、継続できるオーソドックスな指標に立ち戻ることでした。
ラクスル：定点で見続けられる指標を選ぶ
箱崎が見ているのは、マージされたPR数などのオーソドックスな指標。重要なのは、厳密さを追い求めすぎると計測も運用も複雑になり、続かないこと。続かない指標ほど意味がない。
開発には季節要因もあれば、フェーズごとの波もある。短期の数値だけで語れないからこそ、簡単に取れて、定点で、長期に見続けられることを重視する。
そして次に出てくる問いが、「PRが増えたとして、それはアウトカムにどう結びつくのか？」。これはAIだから新しく生まれた問いではなく、開発が事業価値をどう生むかという古くて新しい問いに立ち戻るものだ、と整理されました。
KINTOテクノロジーズ：「Vibe Coding Week」で“説明責任の壁”を越える
和田氏は、Copilotのアクセプタンスレートのような“AIっぽい数字”が、意思決定にあまり効かない実感を語りました。結局、昔から参考になる指標に戻ってくる。
そのうえで、管理職・経営層の認知を更新する施策として実施したのが 「Vibe Coding Week」。
1週間、原則手作業コーディングをせず、AIツール前提で開発する。実験としての意味合いも含めつつ、結果としてPRのオープンからマージまでのサイクルタイムが約35.5%改善しました。
ここで大事なのは、「厳密な比較」よりも目的の置き方です。
- これだけ変わる可能性がある、という感覚を持ってもらう
- エンジニアが安心してツールに没頭できる空気をつくる
- AIツールの“社内での地位”を引き上げる
数字は「儲け」や「人員削減」のためではなく、挑戦しやすい空気と行動をつくる補助線。 この位置づけは、AI導入のメトリクス議論が泥沼化しがちな組織にとって、強い処方箋になります。
まとめ：AIを“組み込む”ための3つの実践原則
最後に、今回の議論を整理します。
1) 使い方を揃えるのではなく、分布をずらす
全員を均一にする発想はコストが高い。
まずは上位の使い方を再現できる層を増やし、可視化し、関心を伝播させる。誰が動くかは固定ではなく、ツール成熟と環境で入れ替わる。
2) ガバナンスは“統制”ではなく“試行を継続する設計”
自由と統制の二項対立ではなく、
- 推奨ラインの提示（自然な収束）
- SaaSレイヤー分け（プレイグラウンドの明示）
- 迷いの呟きに反応する運用（心理的ハードルの低下）で、組織として前に進むためのガードレールをつくる。
3) メトリクスは「正しい数字」より「続く指標」＋「空気を変える材料」
AI特有の指標に寄せすぎない。
継続できるオーソドックスな指標で定点観測しつつ、成功事例で認知を更新し、挑戦できる空気をつくる。数字はゴールではなく行動を変えるための材料。
おわりに：次の一手は「開発全体のバリューストリーム最適化」へ
生成AIによって実装スピードが上がると、ボトルネックは前後工程へ移動します。コードを書く工程が速くなる一方で、要件の詰め方やレビュー待ちといった前後工程が、相対的にボトルネックになる。今回の議論では、まさにその変化が、両社の事例として共有されていました。
ラクスルが進める仕様駆動開発（Spec-Driven Development, SDD）へのシフトも、KINTOテクノロジーズが向き合っているレビュー待ちの課題も、背景にあるのは同じ構造です。
AIによって「つくる部分」が加速した結果、開発全体をどう設計し直すかが、次のテーマとして立ち上がってきたと言えます。
このことは、AI導入の成果が「コードが速く書けるようになったかどうか」だけでは測れない、という点も示しています。
要求定義、実装、レビュー、リリースまでを含めた一連の流れの中で、どこが詰まり、どこを変えるべきか。そこに向き合い続けること自体が、AIを“組み込む”という取り組みの本質なのかもしれません。
