2026/05/31

AI活用を個人技で終わらせないために ①AI活用の組織適用のアイデアと実施

はじめに

AI活用を個人で工夫するフェーズが段々と終わり始め、組織への導入や活用、それによる開発フロー上の課題の顕在化など徐々にフェーズが変わってきていると感じます。

関連して個人的に幾つのトピックについて考えていることがありますが、散らばり始めているので少しずつ整理するメモ書きをします。

個別の内容についてはまた後日深掘りして別記事にするかもしれません。今回は100%手書きで生成AIの利用はゼロです。typoの可能性が高いです。

過去の記事での関連トピックと記事

今回の記事で取り上げる内容

AIのガードレール、Claude CodeとCodexの設定
MCPの導入にあたってのルール整備と運用
OpenTelemetryを活用した利用状況の分析と監査
事業会社として実プロダクトへAI活用を落とし込むために
AIに寄せた技術選定 - pnpm

雑感

AIを個人ではなく開発現場に導入すると、エンジニアの能力がそのまま増幅されるようなイメージがあります。シニアエンジニアは単純に作業量の拡大によって恩恵を受けているでしょうし、ジュニアやミドルのような他人のサポートが必要であったり、コード品質の問題を後から修正しているようなレベル感だとシニアエンジニアの負担も数倍になっているのではないかと思います。

個人の速度を上げるだけでは開発生産性が同じように上がるわけではない、というのが実感としてあります。

今年に入ってからはより一層ガードレール整備、や運用ルールの整備が叫ばれるようになりました。具体的には以下のようなトピックです。

AIにどこまで権限を与えて良いのか
社内情報や顧客情報はどこまで扱わせていいのか
MCPの危険性は
AIが生成したコードをどのような観点でレビューすべきか
若手エンジニアの成長の仕組みはどうするべきか
実装速度に対してテスト速度は追いつくのか
AI活用の評価はどうすれば良いのか

弊社スマレジは開発会社ではなく事業会社なので、活用しました、というだけではなく実プロダクトや業務に落とし込み、投資に対するリターンを出すことが求められ、その評価も必要になります。

ここからは関連するトピックに関する現時点での考えと実際の取り組みをまとめます。

AIツールのガードレール設計と運用

弊社スマレジで利用の主体となっているツールは、Claude Code,Codex(Appを含む),GWS付属のGemini,そして社内用に用意したChatツールです。

個人利用であれば、Claude CodeやCodexはとても便利なツールですが、組織利用の場合は、ガードレールの設計と運用が必要になってきます。

私が現時点で取り組んでいることをまとめると以下のようになります。

管理用設定ファイルの配置

Claude CodeやCodexの管理設定ファイルとしてそれぞれmanaged-settings.jsonやrequirements.tomlなどの形式のファイルが利用でき、それらを利用して外部MCPへのアクセスやリスクのたか位コマンドの実行を制限しています。

.envや認証情報の読み取り、なども制限することができます。そもそもこれらの管理方式を見直す、という取り組みも進めています。

配布にはMDMを利用するのが最適だと考えています。ただ、弊社の利用しているMDMでの管理ファイルの配布が難しいため、スピードを重視してcodexやclaude のパスを上書きするような形でパスを通して薄いラッパースクリプトを実行する形式を選択しました。

ラッパースクリプトでは、Gitリポジトリ上の最新の設定ファイルを都度更新するような形で運用しています。

また、この設定ファイル内にOpenTelemetryのエンドポイントを指定することで、利用状況の分析や監査も行えるようにしています。

注意点としては、この方法が適用されるのが、個人のPC上でのCLI経由での利用、およびCodex Appでの利用に限られることです。

少なくとも記事執筆時点ではGUI上のClaude Codeの各種機能にはそれぞれ管理用の設定画面が存在していたり、Codex Appについても一部適用されるが、Computer Useなどの機能では特に制限を用意できないようでした。

完全に安全なものだけを提供する、というのは仕組み上難しく、とはいえ当初よりシェルやPythonなどで同様のリスクは持っていたわけなので、基本的な方針としてこれらで制御しつつ、OpenTelemetryを活用した監査や利用状況分析の仕組みを構築、社内用のルール、ガイドラインの整備を行うことでリスクを管理していく、という形で運用しています。

MCPの危険性と運用ルール整備

MCPについては、AI関連の知識の差、ソフトウェアエンジリアリングの知識によってリスク認識が大きく異なっているように感じます。

特に、野良のMCPで認証情報の平文利用やバイブコーディングによる脆弱性のあるバージョンのNode利用などが目立つ印象です。

また、現在はツールの起動時にMCPは全て読み込まれる必要があり、必要としない作業でもコンテキストを圧迫してしまうことから基本的にCLIを推奨としています。

弊社で利用しているRedmineなど一部CLIが提供されていないものについてはOSSのフォークや自作CLIなどをAI開発基盤チームというチームを立ち上げて作成、推進を行っています。

個人的に筋がいいなと感じるのは大いに偏見を含みますが、コンテナ利用しているツール、MCPでかつGoもしくはRustで書かれているものです。これらは仕組み上バイナリになるので配布のしやすさ、コンテナの利用のしやすさ、何よりNodeほど攻撃の対象にならない、という点でリスクが低いと感じています。

OpenTelemetryを活用した利用状況の分析と監査

AIツールの利用状況の分析や監査のために、OpenTelemetryを活用した仕組みを構築しています。

AIツールの利用状況を分析することで、どのようなコマンドがどのくらい利用されているのか、どのようなリスクのあるコマンドが利用されているのかなどを把握することができます。

また、監査のために利用状況を記録することで、万が一の事故が起きた際にどのようなコマンドが利用されていたのかを追跡することができます。

特に重要となるのが、利用状況の分析によってコスト最適化を目指す、ということです。

個人的な予想では今後AIツールは同様の価格の利用が難しくなること、現状、投資フェーズなので全エンジニアに提供されているものの実際に効果測定をした場合にシニアエンジニア以外の利用はコストに見合わない、なんならAI活用によって問題が大きくなっているケースを多く観測しており、今後はシニアエンジニアに限定して提供する、という形になるのではないかと考えています。

その際に作業を進めるためのAI利用として、現在のCodexやClaude Codeのような形式ではなく、チームで一つのAIツールを育てていく運用になるのではないか、と予想しています。直近だとHermesやOpenClawが近いかもしれまん。

これらを利用することで、活用の知見やソフトウェア開発の知見を個人で閉じることなく広げていく、かつコスト最適になるよな可能性が高いと思います。

事業会社として実プロダクトへAI活用を落とし込むためのアイデア

大きく二つの方向性があると考えています。一つは開発工程をAIに寄せて再定義し、コストダウンを図ったり、スピードアップを狙う方向性、もう一つはプロダクトにAIを組み込むことで、ユーザ体験の向上や新しい価値の提供を狙う方向性です。

前者についてはいくつかアイデアがあります。

Pull RequestのAIによる分類

AIによるコードレビューでマージするもの、人間によるコードレビューが必要なもの、などに分類するというものです。

例えば単なるドキュメントの更新やテストの追加などではそのままマージしてしまう。設計レベルのものやバグの修正など最終的に人間がOKを出す必要があるものなどは人間のコードレビューが必要、というような形で分類することができます。

分類によって動くレビューエージェントも自作することが必要だと思っています。現状CodeRabbitを弊社では利用していますが、まだまだ観点が弱く、自作エージェント、skillsを利用したCodexの方がより精度の高いレビューができています。

似たようなことは自作エージェントがGitlabやGitHubからWebhookを受け取るようにしておけばPRの取得、レビューコメント投稿、もっといえば修正まで自動で行うことも可能です。

AIによるQA活動

AI関係なく、以前から人力によるQA活動には問題のある組織が多いと思っています。特に、QA活動が開発の後工程になっていたり、自動テストの整備が遅れていたり、リスクコントロールにQAが関われていないケースが多いと思います。

これらについては2パターンのアプローチがあると思います。一つはリスクの高い箇所にリソースを集中させる方法、もう一つはQA組織ごとAIに代替してしまう方法です。多くの場合はハイブリッドを選択することになると思います。弊社においてもWebで完結する場合ならまだしも、プリンターや釣り銭機、タブレットでの実機確認が必要なものが多く、完全な代替にはもう少し時間がかかると思います。

残念ながらホワイトワーカーが生成AIによって仕事を奪われる日は近いと思っており、ソフトウェアエンジニアも一部の上澄を除いては同様の状況になると思います。まだもう少し時間はかかりますが。

その前段でソフトウェアエンジニアが生成AIを活用して他の職種のホワイトワーカーを代替する、という形が進むため、まだしばらくはソフトウェアエンジニアの仕事は残ると思います。おそらく。

AIを組み込んだプロダクトの開発

こちらは基本的に筋が悪いと思っており、基本的に話題性のためにAIを組み込む、という形になると思います。ユーザ体験の向上や新しい価値の提供を狙う、というのは建前で、実際には技術力アピールや一種の流行に近いものだと思っています。まあリソース余ってるならやればいいのではないでしょうか。

ただ、プロダクトの性質によってはAIを組み込むことでユーザ体験の向上や新しい価値の提供ができる可能性もあると思います。例えば、チャットボットや音声認識などの分野ではAIを組み込むことでユーザ体験の向上が期待できます。また、画像認識や自然言語処理などの分野ではAIを組み込むことで新しい価値の提供ができる可能性もあります。

業務システムとしての利用で大きくユーザーにメリットのある生成AIを組み込んだ機能、というのは難しいですが、弊社においてもヘルプサイトや今後は仕様書やドキュメントなどをナレッジベースとして活用することを検討しています。これらはユーザ体験の向上や新しい価値の提供を狙う、というよりは、ユーザが必要な情報にアクセスしやすくする、という形での利用になると思います。

AIに寄せた技術選定 - pnpm

そもそもサプライチェーン攻撃がAIの登場でよりリスクが上がってきており、特にNodeのエコシステムはリスクが高いと感じています。

ゼロデイ攻撃回避のためにpnpmへの移行を採用した組織は多いのではないでしょうか。それでもまだまだ攻撃対策は完全ではないですが、pnpmにはAIに寄せた技術選定の観点でいくつかメリットがあると感じています。

依存関係のフラット化によるリスクの低減
依存関係のロックファイルの明確化によるリスク
インストール前の依存関係の検査によるリスクの低減

これらサプライチェーン攻撃の提言のほかに、依存関係がフラットになること、再利用の方式などからWorktreeの構築において大きく速度的なメリットを得られると考えています。CodexやClaude Codeをそのまま利用している場合でも数個並列して作業することが多いと思います。

AIエージェントの作成

個人的にはCodexやClaude Codeをそのまま利用することはほぼなくなっています。基本的に自作のエージェントやskillsを利用したOSSのエージェント経由で、これらをエンジンとして利用することが多く、自作エージェントの場合はできるだけ自律させるために、社内のPCを一つAIに渡してプロセスを常駐させるような形で運用しています。

特に生成AIモデルの性能が十分に上がってきており、現状のTransformerベースのLLMの仕組みではどんなに進化しても一定の確率的な挙動を含むので、エージェントワークフロー全体の設計が重視され、個別のモデルの性能の差があまり重要でなくなってきていると感じています。とはいえ記事執筆時点ではGeminiを使うことはないと思いますが。モデルの性能への一喜一憂をしている人やコーディングをGeminiでやっている人はちゃんと他のツールを使うか、多少は生成AI利用の前にインターネットを見た方が良さそう。いかに自分の実現したいワークフローを自律したエージェントで代替するか、というのが記事執筆時点での主流な要素になっています。

個人としては現状でも、QA活動を行うエージェント、PRの分類を行うエージェント、skillsによる記憶機構をもつエージェント、プロダクトコードに対する調査を代替するエージェントを作成、一部運用をしており、これらはCodexやClaude Codeを直接利用する場合よりも組織的な運用がしやすく、AI活用の能力を個人依存させない形で広げていくことができると感じています。

組織でのAI活用の今後

おそらくAIツールの利用においては個人での利用から組織での利用に移っていくと思います。残念ながら、個人でのツール利用が許されるのは一定の信頼をすでに得ているシニアエンジニアに限定されるようになるのではないかと予想しています。これはシニアエンジニアが極端に少ない人口比の問題と生成AIの活用においてスケーリングできるのはエンジニアの能力の「質」ではなく「量」である、という性質によるものです。大半の開発組織ではシニアエンジニアは少なく、シニア以外のエンジニアがAI利用において問題を数倍に増やしてしまっているケースが多いと思います。多くの場合はそれらのプロダクトがまだリリースされていない、リリースから時間が経過していないので顕在化していない、ユーザーがついていないのでバレていない、というのが正しいでしょう。また、セキュリティ面では生成AIによる攻撃がまだOSSやサプライチェーンに集中しており、プロダクトが狙われていないことで助かっている、というのもあると思います。

ただし、組織的な生産性向上、開発者体験の向上のために、個人利用ではない、知見を共有できるツールをシニアエンジニア以外も利用できる形にする必要があると考えており、シニアエンジニアはそれらの整備や知識の共有に注力する、というのが現実的な落とし所だと思います。シニアエンジニアが全てやればいいじゃん、というのはもっともですが、組織としてはリスクの集中や教育を無視するわけにはいかないので、ある程度の分散は必要になると思います。

そのためには、本当の意味での自律したエージェント開発を自分たちの業務に合わせたり、反対に自分たちの業務を生成AIに合わせていくような形で作成し、それらに業務を任せていく運用をしていく必要があると思います。現在は生成AIツールをいかに使うか、というフェーズは終了しており、いかに自分たちが生成AIに合わせていくか、というフェーズに入っています。WEBが登場した時も、元々あった業務を電子化したり紙での業務をやめたりと多少IT技術に寄せて業務を成立させてきたはずです。僕は当時を知っている年齢ではないんですが。生成AIにおいても同様で、いかに組織構造や業務を生成AIに適した形に変えていけるか、というのが今後の生成AI活用における組織課題になってくると思います。

本当に自分たちの組織は生成AI活用で生産性、アウトカムが上がっているのか。向上しているのはエンジニアのめんどくさい作業が減っているだけで実際はコストに見合う成果が出ていないのではないかという視点で評価が必要です。特に今年は投資フェーズは終わると見ているので、自分たちの組織に対して冷静な判断をとっていきましょう。