生成AIによる企業変革を導け！生成AI変革チームの足跡 - インテージテクノスフィア技術ブログ

はじめに

生成AIを基盤としたツールがビジネスのライフラインとなった今、社内でそのインフラを整備することが急務となっています。その形や方法は会社ごとの業種・規模・ITリテラシーの高低・社内風土など十人十色です。

今回は、インテージテクノスフィアにて「生成AI変革チーム」が発足してから現在に至るまでの歩みを綴ります。

同じ立場で取り組んでいる方の参考になればうれしいです。

はじめまして！インテージテクノスフィアの堤です。普段は社内向け基幹システムの維持保守運用を担当しており、2025年7月より発足した「生成AI変革チーム」を兼務しています。

生成AI変革チームは「生成AIの力でインテージテクノスフィアのより良い状態への変革を主導する」ために発足しました。

生成AI変革チームは本務リーダー1名、兼務メンバー3名、別部署からの参画メンバー3名で構成されており、兼務メンバーは3割程度、参画メンバーは1割程度の稼働で対応しています。

本記事では、生成AI変革チーム発足後から現在社内で利用を推進しているClaude Codeについて、「決めるまで」、「使えるようにするまで」、「生成AIを浸透させるための取り組み」という流れで、この1年弱に感じたことを記します。

Claude Codeに決めるまで

生成AI変革チームは部署として発足する以前より分科会形式で活動していました。その分科会形式での活動として、2025年6月に技術探求会という、注目技術を実際に試して社内展開する取り組みを行いました。

技術探求会は「MCP」「AIエージェント」「ドキュメント生成」をテーマに、チームに分かれて活動を行い、最後に結果を共有する流れで実施しました。

その中でもAIエージェントは一番ホットな話題（Claude Codeの正式リリースが2025年5月22日）だったこと、そして1行のプロンプトとわずかなやりとりで完全動作するWEBアプリが作成されたことに衝撃を受けました。

また、技術探求会の結果をもとに「Claude Code使ってみた」記事を社内展開したところ、多くの反応があり、社内の関心の高まりを実感しました。

これらを受け、Claude Codeを社内で展開する生成AIツールとして決定しました。

ただし、全員が納得した決定ではありませんでした。

1. 類似ツールと比較

技術探求会ではAIエージェントとして「Cursor」も試しており、それとどちらを採用するのか最後まで議論されました。

Claude CodeはCLI経由の柔軟さと実装のスピード感が強みである一方、CursorはVS Codeをベースに構築されたエディタであり、エディタと結びついた直感的な編集が強みでした。

インテージテクノスフィアには運用業務がメインで開発業務に馴染みのない部署も多く、そういった人はCLIへの忌避感が強いのではないか、逆にすでに馴染みのIDEがある人にとってはCursorへ乗り換えるのはハードルが高いのではないか、などどちらにも決めがたい状況となっていました。

2. 未来の不確実性

生成AI界隈は言うまでもなく圧倒的なスピードで変遷していて、今日優位だったツールが明日にはそうでなくなっていることが当たり前に起きる世界です。今後社内に展開するツールを決定し、半年後、1年後「大失敗だった！」となってしまうのではないかという不安はどうしても拭いきれませんでした。

じゃあどうやって決めたの？

正直なところ「エイヤ」で決定した部分が大きかったです。実装スピードを重視し、Claude Codeを現時点の最適解として選択しました。「あくまでも現時点での軸であり、今後世間の情勢次第で臨機応変に対応していく」ことも、メンバー内で合意しました。

結果として現在では開発・非開発含め業務委託等も含めた従業員の約半数が利用しており、社会的にもClaude CodeはAIコーディングエージェントとして大きな地位を獲得しています。

ただ「運が良かった」とも言えます。生成AI変革チームは多くが兼務のメンバーで構成されており、十分な対応工数を捻出できない場合があります。その中で一度決めたものを覆すほどの大掛かりな動きが素早く行えるのかという点には疑問が残ります。

さらに社内標準として打ち出す以上、方針転換は大きなコストのかかる対応となります。方針転換の妥当性算出・コスト見積もり・社内への説明・環境整備・各部署、社員の対応……想像するだけで気が重くなります。

しかし、生成AIに限らず先端技術の成熟に伴走しようとする場合、どうしてもこうしたリスクをある程度受け入れる必要があります。そういった意味で「覚悟」が必要とされる領域なのだと実感しました。

そのリスクを想定した以上、実際に発生したときのダメージを最小限に抑える具体的な施策をあらかじめ考えておく必要があると思います。なお、この「覚悟」が後の運用でどう試されることになったかは、後述の「最近の課題」節で触れます。

Claude Codeを使えるようにするまで

実際に利用できる基盤を整備する対応を進めました。当初はTeam or Enterpriseプランを契約し、利用者ごとにClaudeアカウントを作成してもらうという方針を考えていました。

しかし、2025年7月当時TeamプランではClaude Codeの利用ができませんでした。さらに大きな問題として、利用者がアカウント作成を制限されるという事態が複数発生しました。

代替手段を探す必要が生じたため、Claudeアカウントを必要とせずClaude Codeが利用できる手段を調査しました。その際に重視されたのは利用者ごとの「権限管理」と「トレーサビリティ」です。トレーサビリティは、従量課金で利用量の多い利用者への個別対応や、浸透状況の把握指標として重要でした。

結果として候補に上がったのは「Bedrock」「Vertex AI」と「LiteLLM」の活用でした。BedrockはAWS、Vertex AIはGoogle Cloudの生成AIプラットフォームで、機能上の差は小さく、社内ハードルの低さからBedrockを選択しました。LiteLLMはプロキシサーバーとして運用する場合に別途サーバー構築が必要な導入コストと、早期稼働を優先したことから見送りました。

運用の工夫

利用者ごとに一意のコスト追跡タグを付与するため、利用者ごとに各モデルをラッピングした「推論プロファイル」というものを払い出す必要があります。また、利用料が大きすぎる利用者に気づくため利用者ごとにAWS Budgetsにて「予算」を作成する必要もあります。

利用申請→推論プロファイルの払い出し→予算の作成→利用者に連絡、というフローを通る必要がありそれなりの手間がかかるものでした。途中から推論プロファイル払い出し→予算作成→利用者連絡用のメール本文を自動化するLambdaをそれこそClaude Codeで実装し、運用負荷を軽減しました。

厳密な検証が不要な小規模実装でも、大きな恩恵を得られることを実感しました。

社内展開の壁

こうして基盤が整い社内展開に踏み出したわけですが、いくつかの壁にぶつかりました。

初期設定の壁

展開初期は以下のようなトラブルが多数発生しました。

利用者がAWS認証に失敗する
- Bedrockを提供するAWSアカウントへスイッチロールするためのJUMPアカウントが介在する構成になっており、普段の業務でAWSを使用しない利用者などJUMPアカウントへのSSO もしくはシングルサインオンやプロファイルの設定でつまずくことが多数あった。
設定ファイル起因で様々な箇所でエラー発生
- 設定ファイル（JSON形式）の構文エラー（カンマ漏れが多かった）
- 設定ファイルの文字コードがUTF8以外になっていた
- 設定ファイルのファイル名が間違っていた（正：settings.json、誤：setting.json）
利用開始手順に記載のコマンドが動かない
- WSL内で利用する想定のコマンドをPowershellで打っていた（その逆）
- 利用者のPCにNodeが入っていなかった

これらが発生した要因として、手順作成時に気づけなかった利用者ごとの環境の差異があったことや、利用者ごとにどれくらいこの種の環境構築に慣れているかの幅が大きいことがありました。

「じゃあ、最大公約数を見つけて詳しく説明すればいいじゃん」と考えるのですがここでも問題があります。現環境がまっさらな状態で、かつ事前に導入が必要なツールも含めてこのようなツールの導入に不慣れな人向けに手順を作成すると「この画面ではこれを選択して……」と説明が必要になります。ここで発生する問題は「人によってわずかに異なる部分の表現が難しい」ことと「変更に弱い」ことです。

一つ目の問題は人によって異なる推論プロファイルが割り振られていることだったり、人によって必要なツールがすでに入っている場合もあるかもしれません。それぞれに分岐説明を加えると正確ではあるものの、見づらくなります。

二つ目の問題は幅広く変更可能性に晒されるということです。Nodeのサイトレイアウトが変更されるだけで手順を書き直さないといけないのは追跡が大変な上、本質的でないと思ってしまいます。

このような問題意識の結果「最低限の手順」を公式手順としながら、補助的に「最も詳細な手順」を用意する二段構えで運用をしています。

この一件で自分たちは一体どの範囲まで利用者をサポートするべきなのか、というのは重要な視点だということを感じました。生成AI変革チームがAWS CLIの導入方法を詳細に説明するのは本当にやるべきことなのだろうか？それでも見捨てるわけにはいかないのか？

トラブル発生の壁

多くのトラブル報告がありました。トラブル報告があるだけでもありがたく、本当に厄介なのはトラブルの知見が溜まっていかないことです。

当初からトラブル一覧ページは用意していましたが、報告は実際の発生件数のごく一部でした。

そこで効果があった施策はハンズオン（パイロットプロジェクト内で実施）の実施でした。その中で導入や初めての利用で発生するトラブルの多くが明らかになり、トラブルシューティングもその場で確認することができました。現在トラブル発生が抑えられているのはこのハンズオンの際に発見したトラブルとその対策を導入手順等に盛り込むことができたからです。

生成AIを浸透させるために

人が何かのツールを使うときはその効果が実感できるから使うのです。効果を実感するにはまず使ってみることが必要です。使うには「使う場面」が必要です。そして使い始めるには準備が必要です。さらに言えばそもそもそのツールを知っていることが必要です。

このように利用者になるための支援を行うとなると「存在の周知」→「導入支援」→「実際に手を動かす場の提供」→「効果測定」が必要なことがわかります。利用のための安定した「基盤」も必要になります。この章ではこれらに生成AIチームがどう取り組んできたかについて述べます。

ルール・ガイドライン・推奨設定

「基盤」として、ルールとガイドライン、さらに利用時の推奨設定について整備を行いました。

ここで印象的だったのは利用者は「どのようなルールなのか」というより「ルールが整備されているか」を気にするということです。後述のアンケートで「社内ルールがどこに書いてあるかわからず使うのを躊躇している」という声が複数ありました。ルールが整備されているという事実が安心材料となっているようでした。

利用時の推奨設定は、具体的には「こういうガードレールは敷いておきましょう」「Rulesなど活用すると良いですよ」というような内容の文章です。導入後の使い方に迷う人の足がかりと、全体品質の底上げを目的に作成しました。ここでは一般化のレベルに苦労しました。社会一般 > 社内一般 > 部署固有 > プロジェクト固有というようにルール化には複数のレベルがあります。「社内一般」レベルで何を推奨設定として書けるかが最大のハードルでした。

AIハブ

「存在の周知」ということで、生成AI変革チームと現場双方での情報交換を効率化するハブとなる「AIハブ」という組織を結成しました。メンバーは各部署から選出し、生成AI変革チームからの情報を現場へ展開し、現場の情報を吸い上げる目的でキックオフしました。

しかし、初期段階では具体的な活動イメージが定着せず活動は情報連絡の域にとどまっており、メンバーにも活動の目的やメリットが見えづらく形骸化の懸念がありました。そこで、AIハブの役割を再定義し、より具体的な施策を考え「事例共有会」を開催しました。

事例共有会では数名に登壇してもらい生成AIを業務で活用した事例を共有してもらいました。また、これに前後してAIハブメンバー間で雑談的に意見交流をしてもらう場を設けました。これによりメンバーが「何をすればよいか具体的なイメージが湧いた」「横のつながりが生まれ、他部署の動向を知ることができた」という成果が得られたことを確認できました。

今後はAIハブを軸として部署ごとのディスカッション会を開催するなど、さらに取り組みを深めていく予定です。

発信活動

社内SharePointにて月1ニュースの配信も行っています。ここでは社内外の1か月でのニュースや取り組み状況に加え、ストック情報として社内の生成AI関連情報がどこで見られるかなども毎回掲載するようにしています。「知らなかった」による機会損失をなるべく減らすことを目指しています。

パイロットプロジェクト

「実際に手を動かす場の提供」と「効果測定」のため実際の業務にて生成AIを導入し、生成AI変革チームも参画しつつ現場導入の効果測定をするパイロットプロジェクトを設けました。現在3件について実施済みまたは実施中です。

具体的には生成AIを活用しなかった場合の工数見積と生成AIを導入した実績工数を提示してもらい工数削減効果を測り、各工程において生成AI活用目線での所感を作業者に記入してもらうようにして工数削減・品質向上の効果を測定しています。

研修の開催

いくつか研修も計画・実施しています。

2026年1月に外部講師を招いた研修を実施しました。そこではLLMについての座学や仕様駆動開発（仕様書を先に書いてAIに渡す開発スタイル）を軸にしたハンズオンを実施しました。外部講師による内容は充実していたものの、前提となる環境面のトラブル対応に時間を取られ、予定していたハンズオンを十分に消化しきれないという結果になってしまいました。

参加者の開発環境の準備状況や前提知識の幅が研修を企画した講師の想定より広かったことで、手前でつまずいてしまう結果となったのだと思います。これは研修だけではなく現場導入でも同じことを感じていて、本質でないところでつまずくもどかしさや周辺領域と生成AIをつなぐ「バリアフリー化」の必要性を痛感しました。

また6月に26年入社の新入社員研修の一枠として生成AI開発研修を実施予定です。実務での開発経験がない人にどう伝えるのが良いのかという点で今までの社内展開とも違った課題がありました。人事ともやり取りを重ねつつ、基本的な開発フローの体験を軸に構成し、生成AIに限らずもともと開発で重要だったことが更に重要になる、というメッセージを乗せることにしました。生成AIを活用した開発が当たり前になるからこそ、本来重要な開発の原則を見落とさないでほしいという願いからです。

新入社員との交流の機会でもあるので今から楽しみにしています。

アンケートによる効果測定

「効果測定」として社内へ生成AIに関するアンケートを月1で実施しています。生成AI変革チームの目標として「週1以上利用者率〇〇%以上」というような具体的な数値目標もあるため、定量的な指標として活用するとともに自由回答欄も設けることで現場の声を吸い上げる目的があります。

アンケートを運用する中で、関心の度合いによってアンケートの認知や回答率に差が生まれるという課題が見えてきました。開発系部署でアンケートの回答率が高い傾向はその表れと言えるかもしれません。

現在ではアンケート実施の連絡を、他の通知方法に加えてメールでも通知することで社内全体での回答率を向上させることができています。

取り組みの成果

浸透率

アンケートの結果、業務での生成AI活用率は非常に高い割合だということがわかりました。Claude Codeを週1日以上利用すると回答した人数も増加傾向にあります。

また、開発・単体テストを行う人の中で、週1回以上開発・単体テストに生成AIを活用する人は、半数を超えています。

工数削減・品質向上

パイロットプロジェクトの結果を集計したところ、工数削減効果は案件によって差があり、効果なしから半減まで幅がありました。一方、工数削減がなかった箇所についても品質向上は認められる結果となり生成AI導入の効果が確認できました。

全体を通して

2025年7月に生成AIチームが発足してから現在に至るまで、個人的に感じたことを最後に記します。

チームのあり方

はじめに書いた通り、生成AI変革チームはほとんどを本所属を別の部署に置いたメンバーで構成されています。兼務構成ならではの大変だった点と良かった点がそれぞれあります。

最も課題だった点は時間の確保です。本務側の業務が繁忙期になるとどうしても兼務側との業務割合調整に頭を悩ませることになりました。

兼務特有の動きにくさは仕方のないことと割り切ったうえで色々と工夫をしてきました。例えばワーク時間を先んじてブロックしておき「忙しくてもこの時間だけは生成AI変革チームのために使う」と決めました。

加えて部署の距離があるメンバーでも一丸となって同じ方向を向くため、キックオフ直後に「ドラッカー式エクササイズ」を実施することで互いの強み・期待値を共有し、チームビジョンを全員で策定することで推進力を高めました。

さらに実質的なリソースを専任換算すると非常に限られたリソースで活動することとなります。多くの対応をこなすことは実際問題難しいことも多く、優先順位と進め方の工夫を常に意識する必要がありました。

兼務だからこそ良かった点はそれぞれの本務部署とのコネクションがある、ということです。「うちの部署で独自にこういう事やってましたよ」と外の情報を持ってこれたり、逆に「それ、うちの部署でヒアリングしてみますね」というように外部展開したい内容をすぐ展開できます。導入初期、現在位置がまだ見えていない段階で情報集めをする際に非常に効果がありました。

浸透させるということは

この期間でやってきたことはつまり、生成AIを社内に浸透させる、ということでした。浸透の壁と浸透の鍵について、それぞれ感じたことがあります。

浸透の壁については以下のようなものがありました。

業務との無関係感： 生成AIに関しては普段の業務で開発ツールに触れる機会の少ない部署ほど「自分たちの業務には関係ない」という認識になりがちでした。これは自然な心理のため、浸透させる側からの働きかけが必要です。

環境構築・初期設定のハードル： 本当は生成AIを使ったあとの話をしたいのにその手前でつまずいてしまう。もどかしいですがここをスキップするわけにもいきません。対象範囲を広げるほど対応が複雑になり、万人向けの導入手順作成は容易ではありません。

「使い方がわからない」以前に「使って良いのかわからない」： 当初は「使い方がわからない」ことが浸透の壁だと推測していましたが、実際には「使って良いのかわからない」という障壁が先にありました。新技術に対する心理的障壁というものはどうしても存在するものです。特に維持保守が主な業務であったり、安定性が重要な基幹システムの開発であれば、新技術というものは一定のリスクを孕んだものとしてまず認識されるのはある意味正しい判断と言えます。そういう意識に対して根拠をもって安全性を担保するということの重要性を感じました。

一方、浸透の鍵は以下のようなものだったと捉えています。

「効果の実感」で使う動機を作る： 身近な人が実際に使ってみて効果を知れるというのが一番効いたと思います。他所の誰かが声を大にして宣伝するより、隣りに座っている人が何となく良さを伝えてくれたほうが効果があるものです。浸透の壁の裏返しで、身近な場所から具体的な効果を聞くことで「自分ごと」として捉えられること、さらに「周りの人が使ってるから使って良いんだ」というように心理的ハードルが下がることが浸透の壁を崩したのだと考えています。

「ルール整備」で使わない理由を消す： 浸透の壁にあった「使って良いのかわからない」という点は、そのルールの中身というよりむしろ「ルールが整備されている」という事実のほうが解消に効果があったと思います。つまりある種の「お墨付き」がある、というだけで、じゃあちょっと内容見てみようかなと選択肢に入ってくる。その「お墨付き」が選択肢に入るきっかけとなりました。

印象に残ったこと

最後に私視点で一番印象に残ったことを記します。それは「思ったより色んな人が独自に動いている」ということです。

生成AI変革チームの一員として、生成AI関連の社会情勢や技術的な知識などはある程度カバーしている自負がありました。その視点で社内を眺めると「全然活用が進んでないじゃないか」とか「頑張って浸透させようとしているけど空回りしている気がする」とか、そういう感覚に陥ることが多くありました。しかし、しばらくすると思っていた以上に「前から自分たちで色々試してみてたんだけど」という声が聞こえるようになってきました。

ここで気づいたことは「自分から声を出さないとやってることは伝わらない」ということと「上から浸透を推し進めても、結果の芽は低い視線じゃないと見えてこない」ということです。

自分のやっていることは声を出さない限り外部から気づかれることはなく、端から見ればやっていないのと同様に映ってしまいます。これは生成AI変革チーム自体も孕んでいる問題で、あるとき社外と交流があった際に組織としての取り組みや成果が伝わっていないと気づくタイミングがありました。その経験が社外にむけて成果を広く宣伝した機会は少なかったなと気づくきっかけとなりました。

また、浸透させようと頑張れば頑張るほど一方的に熱を注ぐような感覚に陥ってしまったことがあります。その状態だと実は上がっていた声が聞こえにくくなってしまいます。「多分あの部署はまだ何もやってないんじゃないかな」という先入観が実態認識を歪めます。確かに上がっている声を拾うためには、こちらから耳を傾けていく必要があるということを改めて認識しました。