はじめに
こんにちは。株式会社サイバーセキュリティクラウドでデリバリ統括部長を務めている黒田と申します。
開発・サポート・TAM（テクニカルアカウントマネージャー）といったプロダクトデリバリ組織を統括し、組織づくりやプロダクトロードマップの策定、各種プロジェクト運営に携わっております。
昨今のAIによる組織・業務の変革を、弊社としても重く受け止めています。
デリバリ組織全般へのAI浸透と、特にコーディングエージェントを前提としたプロダクト開発プロセスの刷新は、私自身の重点テーマとして日々取り組んでいる領域です。
セキュリティを本業とする弊社がコーディングエージェントを組織的に使いこなすには、技術的な理解と組織戦略の両方を同時に動かす必要があります。
その試行錯誤のリアルを、現場とマネジメントの両面からいくつかの記事に分けて記録・発信していきたいと考えています。
エンジニアリング組織を取り巻く環境変化
まずは、AIによって変化しつつあるエンジニアリング組織の環境を概観します。
競争力の差がAI活用力によって急速に拡大
これまでもさまざまな技術革新があったと思いますが、AIの文脈において特筆すべきはその圧倒的な「進化の速さ」です。
AIモデルベンダー各社の熾烈な競争と、加速的にリリースされていく新機能により、「AI活用の最適解」は日々（本当の意味で「日々」）変化しています。
そろそろキャッチアップせねばとドキュメントを読みつつ手を動かし、「こういうやり方で使えそうだな」と思った矢先、わずか1〜2週間でそのやり方が過去のものになってしまった経験をされた方は、きっと私だけではないはずです。
そのような状況にあって、常に最新の情報にアンテナを張り、自分の手で試しながら知見として身につけていくメンバーがいる組織、あるいはそれを可能にする環境を備えた組織と、そうではない組織との競争力の差は加速度的に拡大しています。
組織の存続性にも影響を及ぼしつつある
拡大しているのは競争力の差だけではありません。組織を維持・成長させるための「人材獲得」の文脈でも差が生まれています。
最近、採用面接でエンジニア候補者の方から「コーディングエージェントはどう使っていますか？」と聞かれる機会が増えてきました。2年前にはほとんどなかった質問です。聞き方も変わってきており、「使っていますか？」ではなく「どう使っていますか？」と、すでに使っていることを前提にした質問になっています。
これらの質問の背景にはもちろん「よりよい開発者体験」を求める姿勢もあると思われますが、「AIを業務で活用した経験を積極的に積まなくては生き残っていけない」といったエンジニアとしてのキャリアに対する切迫感も感じられます。
コーディングエージェントの目覚ましい進化によりエンジニア不要論も語られるようになって久しいですが、当のエンジニア自身が、特に成長意欲の高い人ほど、この状況に強い危機感を持っているように感じます。
今後この流れはますます加速し、少し大袈裟な言い方をすると「AI活用が組織の存続可能性にも影響していく」ような危機感を私自身も抱いています。
セキュアな利活用整備の遅れ
組織におけるAI活用の重要性と危機感を踏まえ、「では自社も」となったところで、そこには以下のような壁が立ちはだかります。
- セキュリティリスクへの対応 ... コーディングエージェントが過剰な権限を持った結果、本来開発者が意図しないコマンドの実行やプロンプトインジェクション等による情報漏洩、改ざんといったセキュリティリスクにどう対応するべきか。
- 統制可能なAI利活用 … AIを活用した開発の高速化・生産性向上を実現しながら、データアクセスや利用履歴の監査、機密情報管理、コスト最適化、コンプライアンス遵守を含めたAIガバナンスを、組織としてどのように確立するか。
コーディングエージェントの活用やその環境構築に関する情報は溢れている一方で、それをセキュアに・統制可能な形で組織に展開するための方法論や情報はまだまだ少ないのが実情です。そういった状況もあいまって、AIのモデルや機能進化の速さに対して組織側の整備が多くの組織において後手に回ってしまっているように思われます。
このような状況において、AIを商用環境向けに本格利用しやすいのは、少なくとも以下のような条件を備えた組織ではないでしょうか。
- リスクを許容できる ... 事業リスクが限定的である、または経営判断としてリスク受容の範囲を明確にできる組織
- 自前でリスク低減策を講じられる ... セキュリティ人材含めたリソースやノウハウが十分にあり、自前でリスクのコントロール施策を実行できる組織
弊社はセキュリティを本業とする企業として、安易にリスク許容のアプローチを取るわけにはいきません。リソースが十分かは別として、当然ながら自前のリスクコントロール施策を実行していくアプローチとなります。今後の記事ではこのアプローチに根差した取り組みのリアルを発信していくつもりです。
CSCとして目指すAIドリブンな開発組織
上記のような背景と問題意識において、弊社では以下のような開発組織を目指しています。
爆発的なデリバリ能力の向上
「爆発的」とあえて表現しています。
AI活用の文脈で語られる「生産性の向上」や「業務改善」「自動化」といったキーワードは、いずれも「既存の組織・業務の中にAIを組み込む」といった前提を内包していることが多いものです。しかし、そもそも既存業務が人間中心に設計されていること自体がボトルネックになりえます。
「爆発的」なデリバリ能力の向上というのはこういった漸進的な向上を目指すものではなく、「開発期間が3ヶ月から3週間になった」や「開発要員が10名から3名になった」といったような次元の異なる変革を意図しており、これまで自社が蓄積してきた取り組みの延長線上では決して達成しえないものです。
このような目標を掲げることで、既存の前提やしがらみに囚われることなく、成果（＝顧客への提供価値）を最大化することにフォーカスしたいと考えています。
セキュリティ・ガバナンスをAI活用のエンジンにする
「セキュリティ・ガバナンス」はどうしても守りのイメージが強いことから、「開発スピード・生産性」に関するトレードオフやコストとして語られますが、弊社ではこれらを「安心して事業を加速するためのエンジン」と捉えています。これまでもデータの利活用やDXの文脈はあり、今に始まった考え方ではありませんが、AI時代の今だからこそ更にその重要性を増しているのです。
弊社としてはこれらを体現するため、まずは組織としてリスクを把握・管理可能な状態を整え、策定した対応方針が即座に業務へ取り込まれるプロセスの実現を目指しています。さらに、ガードレールなどのリスク低減を仕組み化することで、現場のエンジニアが最新のAIモデルや機能を機動的に現場投入できる状態を整えていきます。これらを通じて、さまざまなリスクや懸念を最小化し、現場が成果創出のみに集中できる環境の実現を目指しています。
超えるべき壁
目指している開発組織像を実現していくにあたり大小さまざまな超えるべき壁がありますが、まずは大枠として以下の４つを課題設定しました。
壁①：AIポリシーと標準の整備
「とりあえず使ってみて」では済まない以上、ポリシーと標準を先に整備する必要があります。しかしこれが一筋縄ではいきません。
この難しさの核心はAIの利用可否を単純なOK/NGで決められないところにあります。「MCPはどこまで許可するのか」「ローカル環境でどこまでの実行権限を与えるのか」「ブラウザ版は？」「エージェント同士の連携は？」といった具合に、機能やモジュールごとに個別の評価が必要になります。一律OKにしてしまうと、表向きは許可された機能だけを使っているように見えて、実質的には本来アクセスすべきでないリソースへの経路が開いてしまうといった抜け道も生まれやすく、機能セットごとにリスクの度合いも大きく異なります。
かといって、次々とリリースされる新機能すべてを都度網羅的にチェックし続けることは現実的ではありません。厳格にルール化しすぎれば現場は最大限に活用できなくなり、かといってルールがなければ安心して使えない。このバランスをどう取りながら、ポリシーを継続的に更新していく運用を回すか——が本質的な課題です。
壁②：開発組織・プロセスのAI最適化
前述した「爆発的なデリバリ能力の向上」は、既存の組織・業務にAIを組み込む漸進的な改善では達成できません。チーム編成や役割の定義、開発プロセスそのものをAIを前提に再設計する必要があります。
たとえば、一人のエンジニアがAIとともに担える領域は従来とは大きく変わります。設計・実装・テスト・レビューのどこにどうAIを差し込むかによって、チームの適切な規模や役割分担も変わってくるでしょう。
さらに厄介なのは、最適解が一つではないという点です。新規開発なのか運用フェーズなのか、また製品特性やアーキテクチャの違いによってもAI活用の形は変わります。弊社の場合はいずれも取り組み対象となるため、「これが正解」と決め打ちせず、文脈ごとに考え続けることが求められます。
壁③：証跡管理とガードレールの設計
「誰が何をAIに投げたか」を記録し、不適切な利用（機密情報の送信など）を防ぐガードレールをどう設計するか、という課題です。
開発スピードを損なわずに統制の仕組みを設けることは容易ではなく、特に「現場が意識しなくても守られる仕組み」をいかに実現するかが問われます。ガードレールが厳格すぎれば開発の妨げになり、緩ければ統制の意味をなしません。
さらに難しいのは、「不適切な利用」の判定そのものの高度化です。コーディングエージェントと人間とのやり取り、ローカル環境でのコマンド実行を含めた振る舞いといった複雑な状況下では、単純なパターン検知だけでは限界があり、コンテキストを踏まえたセマンティックな解析が必要になります。ここは方式設計に留まらない高度な技術課題を内包しており、技術で対応可能な範囲と運用で補うべき範囲を見極めながら、現実的な設計に落とし込んでいく必要があります。
記録・監視・制御のいずれにおいても、従来の静的なルールベースでは捉えきれない、AIならではのリスクパターンに向き合う設計が求められます。
壁④：サプライチェーンリスクへの対応
コーディングエージェントが生成するコードは、多くの場合、OSSライブラリに依存します。AIが大量にコードを生成する環境では、依存ライブラリのリスク管理をどのように組織として統制するかが重要な課題となります。
コーディングエージェントは人間の何倍もの速さでコードを生成し、ライブラリの選定と追加も自動的に行われます。さらに、また、参照情報が古い場合や、エージェントが適切なバージョンを判断できない場合には、既知の脆弱性を含む古いバージョンが意図せず採用されるリスクもあります。コードの生産量が増えるほど依存関係の総量も膨らみ、管理すべき対象が急速に拡大していきます。
個々のエンジニアのベストエフォートに依存するのではなく、組織全体として継続的に対応できる仕組みをどう設計するか——これはAI活用の拡大とともに、より一層重みを増していく課題です。
今後の記事で書いていくこと
以降の記事では、上記の課題に対して私たちが実際に何を考え、何を選択し、どう取り組んでいるかを書いていきます。
ポリシーや標準の策定といった組織的な取り組みから、具体的な技術選定や設計・実装まで、リアルな試行錯誤を記録していく予定です。
完成した取り組みではなく、現在進行形の試行錯誤です。うまくいっていないことや、まだ答えが出ていないことも含めて書いていきますが、同じような課題を持つ組織の方に少しでも参考になれば幸いです。
本取り組みについて、ご質問やご意見があればコメントいただけると嬉しいです。
Discussion