こんにちは! KINTOテクノロジーズ(以下、KTC)のAIファーストグループで、生成AIの活用推進を担当している和田です。 先日、JDLA(日本ディープラーニング協会)の資格合格者コミュニティ「CDLE」の業種別勉強会にお招きいただき、「個人の発見を、組織の知恵に」というテーマで登壇してきました。本記事は、その内容を再構成したものです。 https://jdla.connpass.com/event/393970/ 1. はじめに KTCはトヨタ自動車のグループ会社で、クルマのサブスク「KINTO」をテックの力で支える内製開発の会社です。 2023年の春、GPT-4とAPI版が出てきたタイミングで内製の生成AIチャットを立ち上げて以来、3年以上にわたって生成AIの活用推進を続けてきました。最近ではKTC/KINTOで培った技術力を、トヨタグループの各社へとアドバイジングや開発支援を通じた提供もしています。 その立場から国内の状況を眺めると、対照的な数字があります。生成AIを「導入済み」と回答した国内企業は57.7%^[ NRI「IT活用実態調査(2025年)」 ]。導入の壁は、もうほとんど越えられています。一方で、AIが利益(EBIT)に5%以上効いていて、かつ大きな価値を生んでいると答えられる企業は6%^[ McKinsey "The State of AI in 2025" ]。導入はしたが、成果を出していると言い切れる会社はまだ一握りです。 おそらくこの記事を読んでいるような、新しい技術への感度が高い方は、すでに仕事が大きく変わっているはずです。メールの下書き、議事録の要約、コーディング支援。少なくとも、これらを全てカタカタ手で打っている人は、かなり減っているのではないでしょうか。しかし問題はその先です。あなたの「周りの人」はどうでしょうか。個人としては価値が出ている。でも、組織としてはどうでしょう。今回のテーマは、個人の成果と組織の成果の間にある、この溝についてです。 2. キャズムのどこに手を打つか ― 今日は「B」の話 本題に入る前に、組織へ新しいものを広げるときのイメージを共有させてください。何度も見たであろう、キャズム理論^[ジェフリー・ムーアが提唱した、新技術の普及プロセスを説明する理論。利用者をイノベーター/アーリーアダプター/アーリーマジョリティなどの層に分け、層の間にある溝(キャズム)を越えることの難しさを論じたものです。]の図です。 新しい技術や文化を組織へ広げるときの手法。A・B・Cのどこに手を打つか これは生成AIの話だから持ち出した図ではありません。DXのときも、RPAのときも、新しい技術や文化を大きな組織に入れる場面では、いつもこの概念を使ってきました。 図にはA・B・Cという3つの矢印を描いています。それぞれが別の打ち手です。みなさんの組織は、いまどの矢印に手を打っているでしょうか。そしてご自身はどの層にいて、どの矢印ならコミットできそうでしょうか。そんなことを考えながら見てもらえればと思います。 A:イノベーターに自由を渡す。 新しいものは、放っておいても勝手に調べ、勝手に始め、勝手に実験してしまう人たちがいます。彼らにできる限り自由な環境を渡す。ただ自由なだけでなく、ガードレールを敷いて「ここでなら安心して遊んでいい」という空間にするのがAです。 B:キャズムに橋をかける。 イノベーターやアーリーアダプターが見つけた価値に、アーリーマジョリティ以降の人たちが追従できるよう、崖になっているキャズムへ橋をかける取り組みです。 C:後ろ向きな層を動かす。 配ってもなかなか触ってくれない、興味を持ってもらいにくい層に、どう使ってもらうか。ここに悩んでいる会社さんは、きっと多いはずです。 今日お話しするのは、このうちBが中心です。Bをやるには、その手前でAも回っている必要があるのですが、本記事では「見つかった価値を、キャズムの向こう側へどう渡すか」に軸足を置きます。 3. 価値創出の両輪 ― 探索と実装 組織で価値を出すには、2つの循環が要る、と私は考えています。 1つは探索。イノベーターやアーリーアダプターにあたる人たちが自由に価値を探せる環境を用意し、「この使い方は効く」という発見を生んでもらうフェーズです。もう1つは実装。見つかった0→1の発見を、組織に固定して10にも100にもするフェーズです。藪まみれの中をしらみつぶしに歩いてゴールを見つけるのが探索だとすれば、見つかった道を舗装して誰でも歩けるようにするのが実装です。 探索だけでは、個人の発見で止まります。IRレポートに載るようなインパクトは、個人技からは出ません。逆に、発見のない組織でいきなり実装(仕組み化)から入ると、舗装すべき道がどこにあるのか分からないまま工事が始まります。これらは両輪であってどちらが欠けても前進することはできません。 ここからは、KTCがこの両輪をどう回しているか、探索→実装の順でお話しします。 4. 探索:トークンマキシング ― 自転車の乗り方は、本では学べない 探索の打ち手の一つとして「トークンマキシング(Tokenmaxxing)」^[あるものを極限まで盛るというネットスラング "-maxxing" を、トークン消費にくっつけた言葉です。]を紹介します。社内のAIのトークン消費を、とにかく最大化する。価値創出はいったん脇に置いて、まず使う量を増やす施策群のことです。 なぜ価値創出にこだわると言っておきながら、消費量に注目するのでしょう。生成AIの正しい使い方は、机上で学べないからです。私はよく自転車の乗り方に例えるのですが、自転車の乗り方を本で学んだ人は、おそらくいません。補助輪をつけて、サポーターをつけて、河原で何度も転んで、身体で覚えたはずです。「AIにこう頼むとうまくいく」「これはAIには苦手だ」という感覚も同じで、試行錯誤からしか生まれません。だから、まずたくさん漕いで、たくさん転ぶことで、AIと効率よく協業する感覚が磨かれます。 トークンマキシングを構成する施策は、「消費を増やす施策」と「消費量を観測する施策」で構成されます。 消費を増やす施策の例としては「手作業コーディング禁止」があります。一定期間、人手でのコーディングを禁止して実装はAIエージェントに任せ、人間は指示と検証に集中する、というものです。コーディング界隈で広まった施策ですが、「手作業での資料作成禁止」のように事務系へのアレンジも利きます。 私自身は資料作成へのこだわりが強く、今でもつい手作業で熱中してしまう時があるのですが、最初の1割は人間が作り、そこから7〜8割まではAIに持っていかせて、最後にまた、人間のこだわりを入れるようにしています。何度も失敗しながら最近ようやくちょうど良いAIとの協業感覚を掴めてきています。 KINTOテクノロジーズで実施した手作業コーディングを禁止する施策「Vibe Coding Week」については、Findyさんによるインタビューブログでも取り上げていただきました。 https://jp.findy-team.io/blog/ai-casestudy/kintotechnologies_vibecodingweek/ もう1つの要素が観測です。増やしっぱなしではコストが爆発するので、誰が・どれだけ使っているかを可視化する。この文脈で有名になったのがMetaの「Claudeonomics」で、8.5万人超の従業員がトークン消費量でランク付けされ、上位250名にはRPG風の称号が与えられていたそうです^[ Fortune「A Meta employee created a dashboard so coworkers can compete to be the company's No. 1 AI token user」(2026/04/09) ]。KTCでも、Claude Codeのメトリクスを各ユーザーから収集し、個人と組織それぞれの使い方を分析する仕組みを動かしています。ツールは配ったけれどその後を見ていない、という組織は、まずここから始めるのを勧めます。 KTCで運用しているClaude Codeメトリクスのダッシュボード(数値はダミーデータ) 5. ただし、トークン消費はハック可能 ・・・ただしトークン消費量は、あくまで間接指標です。 たくさん使った≠価値が出た。実際、Metaの番付では、順位のためにAIを空回しして消費量を水増しする従業員が現れたという情報もあります。そりゃそうですよね。指標は必ずハックされます。入力量で成果を測るのは、印刷したページ数で文章の質を測るようなものなので、報酬や人事評価に直接ひもづけるのは慎重であるべきです。トークンマキシングは、短期的に組織のモメンタムを作る旗印としては効きますが、ずっと続けるものではありません。習熟が進んで消費が落ち着いてくるところまでがセットです。 消費量はあくまで間接指標。指標は必ずハックされる そしてもう1つ、この打ち手には賞味期限があります。これまでのコーディングエージェントの多くは月額定額、いわば携帯のパケ放題のような契約でした。「とにかく使え」が安心して言えたのは、この建て付けがあったからです。ところが課金体系は従量制へ動いています。 GitHub Copilotは2026年6月1日から使用量ベースの課金へ移行します し、他のエージェントも続々と後を追っています。 Uberが2026年のAI予算をわずか4か月で使い果たし、コーディングエージェントの利用に従業員一人当たりの月額上限を設けた という報道も出始めました。 従量課金の世界で大事になるのは、トークンマネジメントや最適化、つまり妥当なコストで成果を増やす考え方です。難しいのは、マキシングを経験しないまま従量課金に入ってしまった組織で、転んだことのないまま管理から始めることになります。もしいま手元に使い放題のプランがあるなら、それは最後のモラトリアムかもしれません。プランが生きているうちに、探索をやり切ることをお勧めします。 定額制(パケ放題)から従量課金へ。「とにかく使え」が言えた時代は終わりつつある ここまでが探索の話。次は、見つけた発見をどう組織に固定するかです。 6. 実装:発見をAgent Skillに固める ― 発見した本人に、文書化まで背負わせない どの組織にも、キャズムでいうイノベーターやアーリーアダプターにあたる人たちがいます。新しいものを勝手に調べ、勝手に試し、「この頼み方ならうまくいく」という良い使い方を見つけてくる人たちです。問題は、その発見が本人の中にしかないことです。 そこでKTCで今増えているのが、 Agent Skill です。Agent Skillとは、AIエージェントに特定タスクの「やり方」を教える再利用可能な手順書のことで、いつ何をするかを書いた指示書(SKILL.md)、手順とOK/NGの線引き、テンプレートやスクリプトといった参照ファイルを1つのパッケージにまとめたものです。属人的だったカンコツを取り出して、誰でも再現できる形に固める。暗黙知やワザを、Skillという形で全員に配ることができます。 Agent Skillは指示書・手順/判断基準・参照ファイルの3点セット KTCの例でいうと、トヨタグループには「物と情報の流れ図(物情)」という業務の可視化手法があるのですが、このドラフトをAIに作らせるSkillを固めて、社内に配布しています。先行する人たちの発見を、お湯を注げば誰でも食べられるインスタント食品に加工して配る、というイメージです。 一方でこうした探索の担い手は、新しい使い方を探すこと自体は好きでも、それを手順書に書き起こすことには関心が薄かったりします。であれば、横串の推進組織が本人のところへ出向いて、「文書化はうちらが代わりにやります」と引き受けてしまうのはどうでしょうか。発見した本人に、文書化の手間まで負わせる必要はないかもしれません。 7. 運用と文化 ― 「手でプロンプトを打たない」という逆説 Skillは作っておしまいではなく、運用が必要です。誰でもSkillを探して使える場所(Plugin Market)を作る。命名ルールを決める・・・検索できないSkillは、存在しないのと同じだからです。ブランチ名や関数名に払っている気遣いを思い出してください。あれと同じ気遣いがSkillにも必要です。ただ、Skillの命名規則のベストプラクティスはまだ世の中に整備されていないので、会社ごとに独自で決めてしまうのが有効だと思います。それから、定期的なメンテナンス。数か月で前提が変わる領域なので、古いSkillは放置すれば負債になります。 Skill運用を支える4つの仕組み(Plugin Market・命名ルール・定期メンテ・対象発掘) そして、そのメンテナンスをどう回すか。ここが地味に大変なところなのですが、KTCではSkillの保守そのものをSkillにしてしまうことを試しています。いわば、Skillを点検・整備するためのSkill群です^[公開されているmizchiさんの「 waxa 」を参考にしています。]。役割を分けた、4つのモードがあります。 検証する:書いたばかりのSkillを、まっさらな別セッションに白紙で読ませ、「ここが伝わらない」という曖昧さや暗黙知を炙り出す。 棚卸しする:Skill群ぜんぶを複数の観点で健康診断し、どれから手を入れるべきかのリストを作る。迷ったら、まずここから。 命名を整える:名前とdescriptionだけを命名規則に合わせて直す。何をするSkillか一目で理解でき、検索で見つかる状態を保つための整備になる。 本文を直す:古いSkill名やモデル名、URLといった陳腐化した参照を、機械的に一括置換する。 コツは、各修正のポリシーきっちり分けて、1つのセッションに何もかもやらせないこと。さきほど「検索できないSkillは存在しないのと同じ」と書きましたが、その状態を保つ作業自体を、人間の根性ではなくSkillに肩代わりさせるわけです。運用とは、こういう地味な仕組みの積み重ねなのだと思います。 Skillの保守そのものをSkillにする。役割を分けた4モードで運用を回す(参考: mizchiさんのwaxa) 文化の面では、事例共有会や勉強会といった地道な取り組みを続けてください。「こんな効くSkill作ったぜ」を見せ合う場は、評価制度ではなく、つい誰かに見せたくなる気持ちで回り始めます。地味ですが、文化醸成はこういう積み重ねでしか進まないと思っています。 最後に1つ、逆説的な話を。個人の仕事を組織の仕事にする上で、プロンプトエンジニアリングのスキルが邪魔をすることがあります。個人が勘とコツでプロンプトを丁寧に調整し、エージェントをいい感じに動かすのは、良いようでいて横展開が非常にしにくい。プロンプト頼みの業務は、それ自体が属人化です。なのでKTCでは最近、組織の仕事にする場合は手でプロンプトを打つのをできるだけやめて、スラッシュコマンドやSkillの呼び出しだけで完結させることを推奨しています。上手に打てる人ほど、打たない。妙な話ですが、組織化とはそういうことだと考えています。 なお、ここまでの打ち手は、KTCがクラウド・AI領域で新しいことに踏み込みやすい立場にある、という前提と切り離せません。新しいことを試し、うまくいったものを少しずつ周囲へ広げていく——そんな意識で取り組んでいるので、キャズムでいう上位層に意識的に時間を寄せています。どの層にどれだけ時間をかけるかのポートフォリオは、自社の立ち位置や方針に従って決め、経営層と握っておくのが筋だと思います。 8. まとめ ― 個人の発見を、組織の知恵に 「個人の発見を、組織の知恵に」今回お伝えしたかったのは、結局この一行です。探索のフェーズでは、トークンマキシングでたくさん試して、転ぶことを恐れない。正しい使い方は、試行錯誤からしか生まれないからです。実装のフェーズでは、発見をAgent Skillのような形に固め、誰でも再現できるようにして配る。そして、仕組みと文化で回し続ける。 探索→実装→仕組み・文化。個人の発見を、組織の知恵に G検定やE資格を持っているような方は、すでに一本のスペシャリティがある状態です。AIは自力にレバレッジをかける道具なので、自力が10の人と100の人では、掛けた後の差がまるで違います。ご自身のドメイン知識と、資格を通じて学んだ知識と、生成AIやAIエージェントを掛け算して、まずはたくさん転ぶところから。そして、転んで見つけた発見を、ぜひ組織に配ってください。 ここまで読んでいただき、ありがとうございました! あなたや周囲の人の発見が、組織の知恵になっていくことを願っています。

こんにちは。アマゾン ウェブ サービス ジャパン合同会社 パートナー ソリューション アーキテクト の深井宣之です。 2026 年 4 月 28 日に「公共分野における AI 活用最新アップデート」と題した Webinar を開催しました。本ブログでは開催内容について Blog にまとめたものになります。投影資料もダウンロードすることが可能です。 本セッションでは、アマゾン ウェブ サービス ジャパン合同会社 パブリックセクター技術統括本部 CSM・プロトタイプ・パートナー ソリューション技術本部 本部長の高田 智己が登壇し、生成 AI の最新トレンドとして「チャットボット + RAG」の時代から「Agentic AI」の時代への移行を解説しました。AWS が提供する AI サービスの全体像を紹介したうえで、中央省庁・地方自治体・ヘルスケア・大学など公共分野における生成 AI 活用の最新ユースケースを多数紹介しました。 セッション概要 資料（PDF）の ダウンロードはこちら から可能です。 生成 AI の最新トレンド ― Agentic AI 時代へ 2022 年末に ChatGPT が登場して以降、生成 AI や RAG（検索拡張生成）が注目を集めてきました。しかし 2025 年 3 月頃からは「AI 駆動開発」「MCP（AI と既存システム連携）」「AI エージェント」といったキーワードが中心となり、AI エージェントが気軽に使える状況が整ってきています。 生成 AI はシンプルなコンテンツ生成を行う「アシスタント」から、単一ゴールを自律的に達成する「生成 AI エージェント」、そしてワークフロー全体を完全自動化する「Agentic AI システム」へと進化しています。Amazon 自身も Alexa+ や代理購買サービス「Buy For Me」など、多くのプロダクトで AI エージェントを活用しています。 AWS の提供する生成 AI サービス AWS では 3 層の AI サービスポートフォリオを用意しています。 AI モデルを作りたい方向け : AWS Trainium / Inferentia によるカスタムチップ、Amazon SageMaker HyperPod などのインフラストラクチャ AI エージェントを作りたい方向け : Amazon Bedrock（基盤モデルへの API アクセス）、Amazon Bedrock Agents、Amazon Bedrock AgentCore、Strands Agents などのフレームワーク すぐに使える AI エージェント : Kiro（AI 統合開発環境）、Amazon Quick Suite、AWS Transform、Amazon Connect など Amazon Bedrock Amazon Bedrock は東京リージョンを含む複数のリージョンで一般提供されている、基盤モデルを活用した生成 AI アプリケーションの構築サービスです。Anthropic の Claude シリーズをはじめ幅広いモデルを利用でき、データプライバシーの観点ではお客様のデータが他のお客様のために使用されることはなく、日本国内クロスリージョン推論もサポートされています。 Amazon Bedrock AgentCore AI エージェントの大規模かつ安全なデプロイ・運用を実現するプラットフォームです。認証・認可（Identity）、ツール管理（Gateway）、実行環境（Browser / Code Interpreter）、セッション記憶管理（Memory）、運用監視（Observability）などの機能を提供し、お客様は AI エージェントのコア開発に集中できます。 AI コーディングエージェント AWS が提供する AI コーディングエージェントとして、生成 AI 統合開発環境の Kiro と、Anthropic 社の Claude Code を Amazon Bedrock 上で利用する方法を紹介しました。Kiro では仕様駆動開発によりプロトタイプからプロダクションまでを支援し、レガシーアプリケーション（Delphi/Pascal）の解析とモダン化にも活用できることをデモで示しました。 公共分野における生成 AI 活用の最新ユースケース 本セッションの後半では、公共分野における生成 AI 活用の最新ユースケースとして、以下の事例が紹介されました。 事例 1: デジタル庁 ― ガバメント AI「源内」 デジタル庁では、政府職員の業務効率化のために生成 AI 検証アプリ「源内（ゲンナイ）」を AWS 上に構築しました。GenU（Generative AI Use Cases）をベースに開発されており、機密性 2 情報の利用が可能です。2025 年 5 月にデジタル庁職員向けにリリースされ、2026 年 1 月から一部省庁で試験的利用を開始。2026 年度には全府省庁約 18 万人の政府職員が生成 AI を活用する大規模実証事業が予定されています。 なお、源内のベースとなっている GenU は AWS Japan の有志チームが開発したオープンソースの生成 AI アプリケーションで、チャット・翻訳・文書校正・要約など業務で活用できるユースケースを提供しており、1,000 を超えるお客様での利用実績があります。 事例 2: 国土交通省 ― AI 書類審査ソリューション「RAPID」 2025 年 4 月の改正建築基準法施行により 2 階建て木造住宅等も審査対象に追加され、審査機関の業務負荷が急増しました。国土交通省では、AWS プロトタイプチームが開発したオープンソースの AI 書類審査ソリューション「RAPID（Review & Assessment Powered by Intelligent Documentation）」を活用し、日本建築防災協会が提供する「建築確認申請図書作成支援サービス」を開発。OSS の活用により開発 2 か月でサービスをリリースし、申請補正指示案件の削減による審査業務負荷軽減が期待されています。 事例 3: つくば市 ― 相談業務効率化 つくば市では、ひとり親支援担当部署において相談記録のテキスト量が多く、転出時の要約資料作成に苦労していました。この課題に対し、GenU をベースにしたソリューションをガバメントクラウド上に構築し、生成 AI による相談記録の要約を実現。大量のケース記録から簡潔な要約を自動生成することで、転入先自治体への情報共有やケース会議での検討を効率化しています。 事例 4: 品川区 ― AI エージェントを活用した問合せ対応自動化 品川区では、人口増加に伴う住民ニーズの多様化や全国的な労働力不足、電話対応業務の負荷増大に課題を抱えていました。Amazon Connect と Amazon Bedrock を活用した AI 自動応答システムの実証実験を実施し、FAQ への自動応答、適切な部署へのルーティング、24 時間対応、必要に応じたオペレーターへのエスカレーションを実現。待ち時間短縮と住民満足度向上、職員の業務負荷軽減、持続可能な行政運営の実現を目指しています。 事例 5: 藤田医科大学 ― 退院時サマリー作成補助 藤田医科大学では、医師や医療従事者が業務時間の多くを文書作成に費やしており、退院時サマリー作成には 1 患者あたり 10〜15 分を要していました。Amazon Bedrock を活用したプロトタイピングプログラムにより、電子カルテ記事を元にサマリー生成の精度を 1 か月で検証。医師作成のサマリーに対し 9 割以上で整合性が取れることを確認し、10 分程度の作成作業が数秒で下書き完成に短縮されました。現在は 31 診療科に展開されています。 事例 6: ソフトウェア・サービス ― 電子カルテシステムへの生成 AI 活用 株式会社ソフトウェア・サービスでは、医師の 52.9% が週 60 時間超勤務、看護師の 7 割が時間外勤務という医療現場の深刻な業務負担に着目し、Amazon Bedrock を活用して電子カルテシステムに生成 AI を連携させました。その結果、サマリー作成時間 50% 削減、心理的負担 70% 低下を実現しています。 事例 7: 東北大学 ― 教職員向け生成 AI アプリ 東北大学では、2020 年に DX 推進チームを発足し、全国の大学に先駆けて生成 AI を導入してきました。GenU をカスタマイズし、チャット・文書作成・議事録作成などの AI ユースケースを全教職員向けに提供しています。検討から 1 か月で内製構築しサービスを開始。会議議事録作成時間が 1/4 に短縮され、ランニングコストも従来の 1/3 に抑えられています。 事例 8: 東京科学大学 ― 日本語大規模言語モデル Swallow の開発 東京科学大学（東京医科歯科大学と東京工業大学が 2024 年 10 月に統合）では、年度末までに大規模言語モデルの継続事前学習を完了させる必要があり、大規模並列の学習用計算環境が求められていました。Amazon SageMaker HyperPod を用いて ml.p5.48xlarge / ml.p5en.48xlarge の学習環境を数時間で構築し、FSx for Lustre と S3 を連携。GPT-4o に匹敵する高性能な日本語大規模言語モデル「Swallow」最新版（Llama-3.3-Swallow-70B 等）のリリースに貢献しました。 おわりに AWS では AI モデルを作りたいお客様へのインフラ提供から、AI エージェントを作りたいお客様へのサービス・フレームワーク提供、そしてすぐに AI エージェントを使いたいお客様向けのサービスまで、多くの選択肢を提供しています。デジタル庁の源内をはじめ、国土交通省、つくば市、品川区、藤田医科大学、東北大学、東京科学大学など、公共分野でも幅広く AWS の生成 AI サービスが活用されています。 本セッションでご紹介した AWS のサービスやソリューションにご興味がありましたら、御社担当の Partner Account Manager にお気軽にご連絡ください。 このブログは、アマゾン ウェブ サービス ジャパン合同会社 パートナー ソリューション アーキテクト 深井宣之が執筆しました。

はじめに データマネジメントPF統括部の平尾です。 Databricksのエバンジェリスト認定資格であるDatabricks Championとしても活動しています。 今回はDatabricks Data + AI Summit 2026（DAIS2026）で発表されたUnity AI Gatewayのアップデートについて、主要ポイントに絞ってご紹介します。 Unity AI Gatewayとは Unity AI GatewayはDatabricksの中央AIガバナンスレイヤーであり、エージェント、ツール、モデル、Model Context Protocol（MCP）を含むAIア