はじめに
生成AIの登場以降「AI利用の社内推進」をテーマに、様々なことに取り組んできました。
振り返ってみると、2025年より前は、目の前の基盤モデルの進化を追いかけながら、優れたモデルを活用したアプリケーションで、何か意味のある成果を生み出そうと、必死に取り組んでいました。そうこうしていると、AIエージェントが話題になりました。AIが自分で考えて、一つの仕事をきっちりやり遂げる姿を目指すということを初めて聞いた時、シンプルですが、初めてプログラムを学んだ時のようにワクワクしたのを思い出します。
その後、AIコーディングエージェントの話題が一気に広がり、私自身もこれに取り組む過程で、大きな危機感を感じました。2025年の春頃からは、IT企業や情報システム部門に携わる方々、そして個人開発者の間で、この技術がもたらす効果や具体的な活用事例、さらには心構えまでもが次々と共有されていたのを思い出します。
進化のペースは想像以上に速く、私自身も時に変化の波に翻弄されながら、柔軟に適応を試みる1年となりました。また、社内で推進する上では、単なるツールの導入を超えて、ある程度の文化の変革を伴う必要性も感じました。
2026年の初めにようやく落ち着いて時間を取るタイミングができたので、これまでに私が取り組んできた 「AI利用の社内推進」に関する活動を、穏やかに振り返ってみました。変化に追従する中で実際に取り組んだこと、目の前に散在している課題、新たな危機感を整理したいと思います。
私自身の立場
筆者である私は、SIerでAWSを扱うCCoE (Cloud Center of Excellence) のリーダーを務めています。これをAWS CCoEと呼んでいます。主な仕事は、AWSの社内活用を推進し、開発、運用、さらには営業や請求管理に関する業務までを、より効率的かつ効果的に進められるようサポートすることです。AWSのベストプラクティスを共有したり、セキュリティやコスト最適化に関するガイドを作成したり、社内のプロジェクトチームに最新情報を提供したりする役割は、CCoEが担っています。
関連して、AWSを扱う業務に取り組むならば最低限このあたりの知識は知って欲しいという狙いから、組織的な技術力の底上げと題して、認定エンジニアの育成にも力を入れています。また、これらの取り組みを社内全体に広げるための技術者コミュニティを運営しており、約3,700名 (2026/1/1現在) の社員が参加しています。
そんな私が取り組む「AI利用の社内推進」のコンテキストとは、AWSが持っているAI関連のサービスに関連する技術です。推進の狙いは、上で挙げた業務に関わる社員や、さらにその先にいるお客様がこれらのサービスを自律的に使いこなし、価値を発揮できるようにすることです。例えば、Amazon BedrockやAmazon Bedrock AgentCore、Amazon Quick Suite、Kiroなどが対象になります。これらに加えて、最近はFrontier Agentsの登場に戦々恐々としています。AI関連のサービスとは言え、AWSの一部ですので、AWS CCoEである私たちが率先してこれらの技術を扱って推進していくことに対して、ここまでの情報を前提に考えれば、大きな違和感は感じられないように思います。
さて、この文章を読みながら、皆様の会社ではどうかと想像してみると、おそらく様々な反応があると思います。うちも同じですと言われる方もいれば、大きな一つのAI推進部門がAWSに関係なく全てを担っていると言われる方もいるでしょう。中には、AWSのAI関連サービスなんて意識したこともないし聞いたこともないという方もいると思います。
ここで言いたいことは、今回のテーマである「AI利用の社内推進」というキーワードは、SIerにとって主語が大きく、職責や立場によって、取り組む内容が異なるだろうということです。AI推進は疲れるという文脈のブログが以前から話題になっていますが、立場は異なるものの、その内容は大変良く理解できます。私も様々な施策を推進するにあたって、より深く想像を至らせる必要がありました。
3種類のAI技術推進
「AI利用の社内推進」と聞いて思い浮かべるイメージは様々であろうと言いましたが、ここでは私が経験しているケースを紹介します。
私自身のAWS CCoEによる推進機能を含めると、3種類の役割があります。
(1) 全社員の業務を効率化するツールを提供
全社員を対象に、業務メール、議事録、稟議、翻訳、要約、検索といった、職種をまたいで共通して必要になるタスクに対して、AIを適用して、業務効率を上げるための推進組織です。既に保管されている社内情報資産の活用が前提となります。このような組織は、濃淡はあると思いますが、多くの会社に存在するのではないかと想像します。
例えば、標準AIチャットツールを開発して提供したり、Microsoft 365のCopilotを社員に使わせたりする役割が該当するでしょう。情報システム部門の役割の延長として成立しているケースが多いのではないでしょうか。
もしくは「社内DX推進」を謳う組織が、社員の業務効率化の手段の1つとしてAI活用を捉え、この役割を担っているかもしれません。
(2) 開発者を支援するツールを提供
システム開発と運用に取り組む社員を対象に、設計、実装、テスト、レビュー、運用手順の整備、障害対応といった、プロダクト開発の現場で日常的に発生する作業に対してAIを組み込み、生産性と品質の両方を底上げするための推進組織です。
例えばClaude CodeのようなAIコーディングエージェントを社内利用できるようにして、コードを書く作業、リポジトリの変更作業や調査、テスト実行をAIが支援することを前提としたプロセスを設計する役割が該当するでしょう。技術の標準化とガバナンスを両立させながらもアジリティを求めるバランスを考えた施策 (これがとてつもなく難しい) を進めます。会社内では組織横断的な開発基盤チームやSRE組織の役割の延長として成立しているケースが多いのではないでしょうか。
また、昨今注目されているAI-Driven Development Lifecycle (AI駆動開発ライフサイクル、AI-DLC) の適用に向けた検証も、この組織が担っているケースが多いでしょう。
(3) システムコンポーネントとしてのAIサービスを提供
自社サービス開発やお客様のシステムを対象に、業務プロセスの自動化、問い合わせ対応の高度化、意思決定支援、品質向上、リスク低減といった、顧客価値に直結するユースケースに対して、AIを設計として組み込み、提供価値を拡張するための推進組織です。
AWSを例とすれば、RAGやエージェントを用いた業務アプリケーションを開発することを前提としたクラウド機能として、Amazon BedrockやAmazon Bedrock AgentCoreなどを社内で利用できるようにして、また、そのプラクティスを提供します。また、モデル選定や評価、ガードレール、監視、コスト最適化まで含めたリファレンスの整備も該当します。
単純に技術的な話に留まらず、契約や説明責任、可用性や保守性の確保が成果の一部になるため、私が運営するCCoEではこの(3)に関する調査研究を行い、社内に積極的な情報提供と、成果の公開を行っています。会社によっては、アーキテクト組織、プロダクト開発部門の役割の延長として成立しているケースもあるでしょう。
ここまで述べてきた3つの役割と、それぞれが扱っている技術を整理すると、以下の表のようになっています。
それぞれの役割で扱う技術は、完全には重ならず、またターゲットとなる社員の層も異なっています。また、この表中の(1)と(2)を社内横断的な組織(ここではAI推進部と表記)が担い、(3)をCCoEが推進しています。
これを見て、全部同じ組織で進めないのかと思われる方もいるでしょう。組織の作り方は各自様々だと思いますが、現状、この役割分担がベストであると考えている理由を説明します。
AWS CCoEとAI推進部がそれぞれ担う推進活動
そもそもCCoEは、企業がクラウドサービスを戦略的かつ効果的に活用するために、必要な人材・知識・ノウハウを集約し、全社横断で導入・運用を推進・統括することをミッションとする組織です。私のケースでは、アジリティを確保するために、クラウドサービスごとにCCoEを設立しており、AWS CCoEが私の管轄です。
AWS CCoEは、AWSの情報が集まるハブのような存在にもなっています。AWS CCoEは、個別の現場に忖度することなく、最新の情報をPush型で提供しています。また、AWS CCoEを中心に双方向の情報共有を行えるようにして、各チームで同じような成果物やプログラムが再発明され続ける (あるチームの成果が互いに共有されにくい状態) を防ごうとしています。
このような課題の克服はCCoEがなくても簡単だと思われるかもしれませんし、実際に昔は私もそう思っていましたが、現実問題として、責任ある業務と向き合いながらの活動は、非常に苦労しました。そのため、専任組織を作ろうと話し、今の形になったのです。このあたりの経緯については、ぜひこちらのスライドをご覧ください。
社員3,000名が参加する社内AWS技術者コミュニティ 「TAWS-UG」運営の舞台裏
AWS CCoEの目線で見れば、Amazon BedrockなどのAIサービスは、数多くのAWSのサービスの1つと言えます。AWS CCoEの活動の延長でキャッチアップして、社内にプラクティスを広めていくというのは理に叶っていると考えます。また、AWSを社内で利用するための手続きやルールを作っているのもAWS CCoEです。私のケースでは、今までに発信した情報と最低限の整合性を取る形で情報を発信する責務があると考え、活動しています。
AWS CCoEは、AI推進部を含む全ての開発組織に対して、AWSのAIサービスを利用する上での考え方から具体的なサービスを組み合わせるプラクティスまで、能動的に情報提供を行っています。AI推進部は、目的を果たすために、AWS CCoEが発信する情報を参考にすることがあります。
AI推進部は、社員に使わせるAIツールやチャットサービスを全体に公開する役割を持ち、その影響範囲は全社員に及びます。AWS CCoEはAWSを利用してシステム開発を行う全ての社員に影響を及ぼします。AWS CCoEが公開したプラクティスをAI推進部が参照し、逆にAI推進部が公開 (または利用許可) したツールをAWS CCoEも使います。
AWS CCoEが取り組んでいる活動
ここでは、私が取り組んでいるAWS CCoEで進めている、AI技術の社内推進に関わる活動の一部を紹介します。
(1) 認定エンジニアの育成
AWSの認定資格である「AWS Certified AI Practitioner」「AWS Certified Machine Learning Engineer – Associate」の取得を中間目標に置いた、生成AIとAIエージェントに関するスキル習得プログラムを公開しています。認定試験はAWSのAIサービスを扱うために必要なスキルを網羅的に問うものであり、試験ガイドは何を学んだら良いかを知るために非常に参考になります。試験の合格を目指すことで、偏りのないスキルの習得が可能と判断して、推進することにしました。
そこで、試験の合格に必要なスキルを身に付けるための独自のコンテンツを、AWSが提供する試験ガイドと公式ドキュメントを参考に開発しました。試験勉強会の動画も公開しています。また、試験勉強には欠かせない模擬試験は、問題と解説の組み合わせをAIエージェントに生成させています。
この事例は、AWS公式の「日本の生成 AI 事例集」にも掲載されていますので、宜しければご覧ください。
一連のコンテンツの社内公開以降、AI Practitionerの合格者は200名近くに達しており、一定の育成効果があったと自負しています。
(2) AWSのAIサービスに関する理解の拡大
ただ、知識という武器を手に入れたとしても、仕事を生み出すことが出来なければ、その使い所がないと考えています。そこで、AWSのAIサービスを活かしてどのようなことができるのか、既にAWSを使っているシステムでどんな改善効果が得られそうかという、一番基本的なところから知ってもらうためのコンテンツを開発しました。
コンテンツは2種類あり、それぞれ「生成AI」と「エージェンティックAI」について、解説を公開しています。これらのコンテンツには、正直なところAWS以前の話も含まれていますが、総合的に理解を深めていただくためには必要不可欠と考え、作成しています。
生成AIの解説は、ユーザ体験やビジネスへの影響を解説した後、AWSが提唱する生成AIスタックの全体像、スタックを構成する各サービスでできること、責任あるAIの実装の詳細で構成されています。
- 生成AIの基本理解
- 生成AIが生み出す価値
- 業界での動向とビジネス機会
- AWSにおける生成AIの全体像 (Generative AI スタック)
- アプリケーション層 (ユーザに近い層)
- モデル層 (基盤モデルと開発ツール)
- インフラ層 (学習・推論を支える基盤)
- 安全で信頼できるAIの実践 (責任あるAI)
- 導入時に押さえるべき要点
エージェンティックAIの解説は、自律的に思考して行動するAIの存在を前提としたユーザ体験の改善について述べ、多様かつ具体的なユースケース、アーキテクチャ、各サービスの解説で構成されています。
- エージェンティックAIとは
- AWSが持つエージェンティックAIのビジョン
- AIエージェントの発展の歴史
- 生成から行動へ
- エージェンティックAIの成熟度
- マルチエージェントシステムとエージェントの種類
- エージェントの信頼性とその限界を知る
- 運用の卓越性を確保するには
- AIエージェントが有効な3つの価値領域
- カスタマーアーキタイプ
- アーキテクチャ全体像
- どんな選択が可能か
いずれのコンテンツも、読み手にこれらの知識が備わることで、目の前の課題の解決や実装のアイデアが思い浮かびやすくなり、AWSを活用したアプローチがある程度明確になることを意図しているものです。
(3) 技術勉強会の開催
生成AIやエージェンティックAIに関連した知識をアップデートするための機会として、勉強会を不定期に開催しています。3,700名もの社員に広く拡散するための公開勉強会に加え、事業部門側の方々と個別に調整して開催する勉強会もあります。最近は、後者の方が増えてきた印象です。
直近では、AWS re:Invent 2025のre:Cap (振り返り) イベントに、お客様も含む400名超が参加し、大変に盛り上がりました。
AI利用に関する様々な考え
現在の施策運営の形に至るまでに「AI利用の社内推進」について考えたことをまとめてみます。SNS上でも様々な議論があり、様々な意見が飛び交っています。以下に書くことも、これが絶対だと主張するのではなく、あくまでも一つの事例を紹介するものです。
どうしてAI推進部に全てを任せないのか
AWS CCoEである私たちの仕事の1つは、AWSに関連した最新のプラクティスを社内に発信し続けて、自社が持つ知識のアップデートを繰り返していくことです。情報の発信先は3,700名が参加する社内コミュニティです。その中にAI関連の情報が含まれていて、現在は非常にウエイトが高くなっています。アップデートの頻度から考えれば、今後も、AI推進部の施策の方針転換に影響し、介入するような情報発信が多発するでしょう。
もしAWS CCoEとAI推進部が1つの組織になっていると、AI推進部の全社施策との整合を取るために、最新のAmazon Bedrock等のアップデート情報を敢えて発信しないという選択があるかもしれません。しかし、前述のように、事業部門にもツールやサービスの採否を判断する裁量があります。そのため、社内政治や施策との整合性を過度に気にして、情報発信にフィルタを掛け過ぎることは、健全ではないと考えています。現状は、AWS CCoEにもAI関連の情報発信の裁量が引き続きあり、社内で互いに忖度せず、危機感を健全に共有し合える、今の形が一番良いと判断しています。
社内でAI利用の標準化をしたほうが良いのか
新しいツールやサービスが登場した時に、その利用に縛りを設けてしまうようなことは、避けたほうが良いでしょう。例えば「社内ではこのツールだけが認められている、それ以外は認められない」というものです。AI関連のアップデートは非常に早く、変化に柔軟に適応しなければ、最大の効果を発揮することは叶わないと考えます。
ただし、AIで活用する社内のデータはマスキングしてここに置きましょうとか、ガードレールにこれだけは設定して使いましょうという、守るべきものを守るための標準化はあったほうが良いと思います。AIであれば「責任あるAI」というキーワードで発信されている情報を参考に、検討していくことになります。
求められるスキルは変わるのか
私の周りでも、AIコーディングエージェントの普及によって、少なくともプログラムを書く上での作業の進め方は劇的に変わりました。いきなり頭からコードを書き始めることは減り、AIにコードを書かせて編集していくスタイルが増えました。
最近では、先に仕様書をAIに書かせて、次に仕様書に沿ってコードを書かせる、仕様駆動開発の検証も進んでいます。AIへの指示の出し方を磨きつつ、AIが書いたコードの正当性を検証し、妥当性を確認しなければならないため、より上流のスキルが求められるように変わってきています。逆に言えば、このあたりのスキルが欠けることで、AIで作業時間を短縮するはずが、逆に時間がかかってしまうというケースも出てくると考えています。
ツールの特徴や効果的な使い方を学ぶことは当然として、敢えてソフトウェアエンジニアリングを今一度学び直すということも大事だと、私は考えています。このように考えると、今後CCoEとして発信する情報にも、ひと工夫が必要そうです。
何を社員に発信していくのか
まずは、AI関連のツールやサービスへの臨み方が大事だと考えます。基本的な使い方 (こう使えばこう動く) に関する情報は溢れています。情報のキャッチアップを求めていくのは当然です。しかし、これらを読んだだけですぐ使いこなせるのか、また他者に説得力のある説明ができるのかというと、そんなに簡単ではないでしょう。日頃から興味や関心を持ち、手を動かして学んでいくことが大事です。そのツールやサービスで何ができ、何が変わるのかということを肌で学ぶには、手を動かし続けるしかありません。このことを粘り強く訴えていく必要があります。
次に、身の回りに起きている小さな課題や困りごとに目を向け続けることが大事だと考えます。ツールやサービスの使い方を覚えたら、目の前の課題をAIでどう解決できそうかということを考え、実際に取り組んでみるのが良いです。そのためには、開発者以外の様々な立場の方と会話し、見識を広げることも大事だと思います。
まとめに代えて
この記事では、私が今日までAWS CCoEとして取り組んできた「AI利用の社内推進」について、各組織の役割を整理しながら、熟慮を重ねて取り組んできたプロセスや結果をまとめました。この内容が少しでも誰かの役に立てば幸いです。
ただ、生成AIやAIエージェント (エージェンティックAI) の進化のスピードは相変わらず凄まじく、今後も、次々と新しい技術が登場してはプラクティスを塗り替えるということが繰り返されていくと考えています。AI関連のツールやサービスが頻繁にアップデートするのと同じく、これらを受け止めて推進する組織のあり方もアップデートすることが前提です。今日のベストが明日にも変わり、もしかすると、取り組んできたことが無駄になるかもしれないという状況ですが、恐れていては何もスタートしません。前述の通り、手を動かし続けるしかないと考えています。
2026年も引き続き、果敢にチャレンジを続け、変化を恐れずに受け入れて、取り組んでいきたいと思います。