こんにちは、サイバーセキュリティと生成AI活用推進を担当しているたなちゅーです。

KINTOテクノロジーズ（以下、KTC）では、以前の記事で紹介した全社横断プロジェクト「AI-Native Dev」を中心に、AIネイティブな開発・業務プロセスへの変革を進めています。いまでは職種を問わず多くのメンバーが、日常業務のさまざまな場面でClaudeを利用しています。そうした環境の中で「パワーポイント作成もAI-Nativeにしたい」と考えるメンバーが現れ、それぞれがClaudeで利用しやすいパワポテンプレを自作するようになりました。こうした自作テンプレが社内で活発に使われている様子を目にしたことが、今回の取り組みを始める大きなきっかけです。

一方で、この動きには課題もありました。

• 自作テンプレは個人ベース・非公式にとどまり、社内に複数の様式が並行して存在している
• AI経由で生成したスライドの見た目がバラバラで、会社の資料としての統一感が出ない

そこで、これらの個人の創意工夫を束ねて、「AIが利用しやすい会社公式パワポテンプレ」として一本化・全社展開するプロジェクトを立ち上げました。この記事では、その取り組みを紹介します。

取り組みの概要

目指した状態

プロジェクトのゴールはシンプルで、「Claudeに指示するだけで、KTC公式デザインに揃ったスライドが出てくる」状態を全社員に提供することです。これにより、次の3つの価値を狙いました。

3つ目が本プロジェクトの特徴的なポイントです。単にテンプレを作るのではなく、すでに個人が生み出していたAI-Nativeな工夫を「会社公式」の標準にすることを重視しました。AI-Native Devが文化醸成の軸として掲げてきた「個人の知見を組織全体で活かす」を、パワポテンプレという誰にとっても身近な題材で実践した形です。

体制と進め方

推進はAI-Native Devが担い、テンプレートのデザインはクリエイティブグループが担当する協業体制で進めました。今後は技術広報グループとも連携しながら、利用促進に取り組んでいく予定です。

全体像は次のとおりです。

進め方として特に大事にしたのは、次の合意です。

「AIで再現しやすいフォーマット / スタイルガイドはどうあるべきか」をAI利用者側から逆算してデザイナーへインプットし、デザイナーがそれを受けてフォーマットを設計する。

デザインが完成してからAIに対応させるのではなく、設計の段階から「AIが出力しやすい構造」を要件に含めています。この取り組みを「AI-Native」と呼んでいるのは、こうした進め方によるものです。

フェーズは次のように区切りました。

いきなり完成品を作るのではなく、まず有志の自作テンプレをたたき台として展開してフィードバックを集め（公開後50名以上が閲覧・ダウンロード）、その声をもとに公式版を作る、という2段階を踏んでいます。

AIが利用しやすいテンプレートの設計

完成したテンプレートには、AIとの相性を高めるための工夫がいくつも入っています。

ヘッダー＋ボディのコンポーネント構造

スライドを「ヘッダー＋ボディ（シングル / スプリット / マルチカラム）」というコンポーネントの組み合わせとして構造化しました。AIは自由なレイアウトを毎回ゼロから作るよりも、決められた部品の組み合わせを選ぶ方が安定して高品質な出力を返せるためです。

レイアウト選択ルールのスキル化

「どんな内容のときに、どのレイアウトを選ぶべきか」というルールをClaudeのSkill（スキル）として整備しました。これにより、毎回テンプレファイルを渡さなくても、Claudeが自律的に適切なレイアウトを選択してスライドを組み立てられます。

使い方は3通り

展開にあたっては、作業スタイルに合わせて3通りの使い方を用意しました。

方法1は、Claude Coworkやチャットにテンプレファイルとアウトラインを渡して「このテンプレを踏襲して」と依頼する、いちばん手軽な入口です。

方法2のSkillにはテンプレのデザイン情報が組み込まれているため、社内のプラグインマーケットプレイスから一度インストールすれば、ファイルを用意しなくても依頼するだけで公式デザインの資料が生成されます。

方法3のClaude Design向けには、配色・フォント・レイアウトを定義したデザインシステム（ダーク・ライトの2トーン）を用意しました。pptxファイルとして配布・編集したい資料は方法1・2、見た目の作り込みを優先したい資料は方法3、という使い分けです。

「迷ったら方法1から」という導線にして、AIでの資料作成に馴染みのない社員でも一歩目を踏み出しやすくしています。

おすすめの進め方は「先にアウトラインを固める」

どの方法でも共通して案内しているのが、いきなりpptxを作らせず、先にClaudeと壁打ちしてアウトラインをMarkdownで固める進め方です。生成されたpptxに「2枚目を直して」「構成を変えて」と修正を繰り返すと、そのたびにファイルの再生成が走り、時間もトークンも大きく消費します。内容の試行錯誤はMarkdown上で済ませ、pptxの生成は最後の1回だけにすることで、トークン消費を大きく抑えられます。

また、生成された資料の数値・固有名詞・事実関係は必ず人の目で確認する、という運用もあわせて案内しています。テンプレ自体も作って終わりではなく、利用者へのヒアリングやフィードバックフォームを通じて、レイアウトの追加なども含めて継続的にブラッシュアップしていく予定です。

おわりに

「AIに指示するだけで、会社公式デザインのスライドが出てくる」のは、使ってみるとシンプルに便利です。そして、それを実現する鍵は高度なAI技術ではなく、AIが扱いやすい形にテンプレートという「型」を設計し直すこと、そしてその型をデザイナーとAI利用者が一緒に作ることでした。デザインルールをどこまで厳密に縛り、どこを緩めるかの塩梅も、この過程で見えてきた収穫です。

個人の創意工夫として始まったAI-Nativeな動きを、組織の公式な成果に引き上げる。このモデルはパワポテンプレに限らず、さまざまな社内資産に適用できるはずです。この記事が、同じような取り組みを検討している方の参考になれば嬉しいです。

AI-Native Devの活動やナレッジは、引き続きテックブログで発信していきます。最後まで読んでいただきありがとうございました！

• 2026年7月31日、KINTOテクノロジーズ（以下、KTC）のOsaka Tech Lab JCTを会場として、Anthropic公認のコミュニティイベント「Claude Managed Agents Workshop」が開催され、約30名が参加しました。主催はClaude Community Ambassadorであり、KTC社員でもある森田さんです。
• Claude Managed Agentsは、エージェントを動かすための土台（実行制御・サンドボックス・履歴やファイルの保持）をAnthropic側が用意してくれるサービスです。利用者はエージェントの設定とメッセージの送信に集中できます。
• ワークショップの教材は誰でも参照できる形で公開されています。イベントに参加していなくても、同じ手順でエージェントを作って動かせます。
• ハンズオンで唯一つまずいたのはClaude側ではなく、外部サービスであるJina AIのAPIキーでした。キーに無料トークンが残っているとは限らないので、教材を試す前に残トークンを確認しておくと足を止めずに進められます。

はじめに

こんにちは、KINTO開発部でフロントエンドエンジニアをしている齋藤です。普段はKINTOのシミュレーションや申し込み、マイページの開発を担当しています。

2026年7月31日（金）、KTCのOsaka Tech Labを会場として、Claude Community Event「Claude Managed Agents Workshop」 が開催されました。私は会場提供・運営サポートを担当しつつ、参加者としてハンズオンにも取り組みました。

本記事は、その開催報告です。

 当日のエントランスの様子

開催したイベントの概要

タイムテーブルは次のとおりです。

会場提供の経緯

主催の森田さんはAnthropicから認定されたClaude Community Ambassadorであり、同時にKTCのPrincipal Generative AI Engineerでもあります。社内向けのAIエージェント構築ワークショップを開催した話は、こちらの記事で紹介されています。

今回のイベントは、その森田さんが場所貸しイベントとして社内で起案し、運営協力者の募集がかかったところに私が手を挙げた、という流れで実現しました。

会場：Osaka Tech Lab JCT

Osaka Tech Labは、東京・名古屋に次ぐKTCの第3の拠点です。2022年に心斎橋で開設され、2025年夏にJR大阪駅直結のノースゲートビルディングへ移転しました。「集GO！発SHIN！CO-LAB」というコンセプトを掲げていて、会議室にGARAGEやPIT、モータープールといった車にちなんだ名前が付いていたり、執務室の床がレーシングラインを模した遊び心のあるデザインになっていたりします。

今回使用したOsaka Tech Lab JCTは、その20階にあるイベントスペースです。40名ほどを収容できる広さで、今回の参加者は約30名でした。JR大阪駅直結という立地なので、金曜夜のイベントでもアクセスしやすい会場です。

アクセス方法はKINTOテクノロジーズOsaka Tech Labにご来場のかたへで写真つきで案内しています。

当日の様子

当日は、Anthropicでコミュニティ活動を担当されている辻さんにもご来場いただき、会の冒頭にご挨拶をいただきました。大阪でのアンバサダー主催イベントは今回が初めてであること、今後も関西でコミュニティを盛り上げていきたいというお話をされていました。

続く30分は、森田さんによるClaude Managed Agentsの解説パートです。

 解説パートの様子。スクリーンに投影されているのが当日使用した教材です

その後はハンズオンに移ります。各自のペースで進める形式だったので、全員が黙々とキーボードを叩いている時間と、手が止まった人が周りに聞いて質問が飛び交う時間が、交互に訪れていました。

各テーブルにはお菓子が用意されていて、つまみながらハンズオンを進められました。

 ハンズオン中の会場。各自のペースで進めます

もくもくと作業が進むなか、森田さんが会場を回って、困っている人がいないか声をかけてサポートに入る場面もありました。手を挙げれば主催者が直接見に来てくれるという体制だったので、普段Claude Codeを使っていない人でも安心して参加できるイベントだったと思います。

 サポートに入る森田さん

参加者の年齢層は幅広く、学生の方も参加されていました。

 Osaka Tech Lab JCTは40名ほどを収容できます

参加者には、Claude Managed Agentsを試すための$50相当のAPIクレジットが配布されました。

さらに辻さんからは、Anthropic公式のノベルティも提供していただきました。

 Claude Codeのマスコットキャラクター「Clawd」のぬいぐるみ。サングラス姿と、白衣にフラスコを持った科学者姿の2種類がありました

 M5Stack Cardputer ADV

数に限りのあるノベルティは希望者が用意された数を上回ったため、じゃんけん大会でもらえる人を決めました。会場が一番盛り上がった瞬間だったかもしれません。

 じゃんけん大会の様子

 最後に参加者の皆さんと。手にしているのがClawdのぬいぐるみです

Claude Managed Agentsとは

ここで、当日のテーマだったClaude Managed Agentsについて、私が理解した範囲で整理しておきます。

AIエージェントを自分でゼロから作ろうとすると、アプリケーション側で用意しなければならないものが意外と多くあります。モデルを呼んでツールを実行し、その結果をまたモデルに渡す、という繰り返しの制御。ツールを安全に動かすための実行環境。途中で生成されたファイルや会話履歴の保持。Claude Managed Agentsは、この土台をAnthropic側がまるごと用意してくれるサービスです。利用者が用意するのは「どんなエージェントにするか」という設定と、「何をしてほしいか」というメッセージだけになります。

Messages APIとの棲み分けは、公式ドキュメントではきめ細かい制御が欲しいならMessages API、数分から数時間かかる長時間実行タスクや非同期処理ならClaude Managed Agentsという整理になっています。

登場する概念は4つです。

ハンズオンも「エージェントを作る → 環境を作る → セッションを起動する → メッセージを送る」という順番をそのままたどる構成になっていたので、この4つの関係は手を動かしているうちに自然と頭に入りました。

サンドボックスの中では、bash、ファイルの読み書き・編集、glob・grep、Web検索・取得といったツールが最初から使えます。ここにMCPサーバーを繋げば外部サービスのツールも呼び出せる、という組み立てです。

料金は次の2軸です。

• セッションのなかでモデルが使ったトークンぶんの、通常のAPI料金（プロンプトキャッシングの乗数も同じように適用されます）
• セッションランタイム（セッション時間あたり$0.08）

セッションランタイムはミリ秒単位で計測され、セッションがrunningのあいだだけ加算されます。次のメッセージを待っているidleの時間は加算されません。裏を返せば、エージェントを長時間放置しても待機中のコストは増えないということで、これは長時間タスク向けという位置づけと整合しています。なお、セッション内でWeb検索が走った場合は1,000検索あたり$10が別途かかります。

本記事執筆時点でClaude Managed Agentsはベータ版です。詳細は公式ドキュメントと料金ページを参照してください。

ハンズオンをやってみた

私は受付を担当していたため、ハンズオンの開始が少し遅れました。さらにイベントの様子を撮影しながら進めていたので、上級には届かず中級までの到達です。

教材は初級・中級・上級の3段階構成になっていて、内容は次のようなものでした。

• 初級：テンプレート「Deep researcher」からリサーチエージェントを作る、チャットで設定を自動生成してMicrosoft LearnのMCPサーバーを使うクイズエージェントを作る、自由演習
• 中級：Jina AIのMCPサーバーにつながるWebリサーチエージェントを、コンソール・CLI（ant）・Python SDK の3通りで作る
• 上級：分析レポート（スライド生成）、スケジュール実行でGitHub Pagesを毎朝更新、Gmail連携、記憶するエージェント、マルチエージェント

同じエージェントをコンソール・CLI・SDKの3通りで作らせる中級の設計が特に良くできていて、画面操作で理解した概念がそのままAPIのリソース構造に対応していることが体感できました。

そして特筆すべきは教材の完成度です。説明が丁寧で画像も豊富に用意されていて、公式が提供した教材と言われても遜色ないなと感じる内容でした。おかげでClaude Managed Agentsの部分ではまったくつまずくことなく進められました。

つまずいたのはJina AIのAPIキー

強いて挙げるなら、中級で使うJina AIのAPIキーが唯一の詰まりどころでした。私のAPIキーには無料トークンの残りがなく、Jina AIのツールを呼び出せませんでした。

中級で作るのはWeb検索するリサーチエージェントで、検索はJina AIのMCPサーバー経由で実行します。この検索系のツールはAPIキーが必須です。APIキー自体はアカウント作成もクレジットカード登録もなしにトップページから取得できるのですが、そのキーに無料トークンが残っているとは限りません。

:::message これから教材を試す方は、先にjina.aiの「API KEY & BILLING」タブでAPIキーの残トークンを確認しておくと、中級で足を止めずに進められます。 :::

イベントに参加していなくても教材を試せます

このワークショップの教材は、森田さんが作成したものが公開されています。

• Claude Managed Agents Workshop（教材サイト）

イベントに参加していなくても、事前準備から上級まで同じ手順をたどれます。Claude Managed Agentsを触ってみたい方には、公式ドキュメントを読み込むより先にこちらを一周するのがおすすめです。

:::message この教材はAnthropicの公式コンテンツではなく、非公式の学習教材です。ライセンスがCC BY-NC-ND 4.0のため、本記事では中身の転載はせず、リンクの紹介にとどめています。 :::

8月にも同じ内容のワークショップが開催されます

今回のイベントは申込がキャンセル待ちまで伸び、参加できなかった方が多く出ました。そうした方に向けて、同じ内容のワークショップが8月にも開催されます。

解説のあとハンズオンという流れは7月31日と同じ構成です。申込には承認が必要なので、詳細はイベントページを確認してください。

おわりに

Claude Managed Agentsは、エージェントの設定とメッセージの送信だけで自律エージェントを動かせるプラットフォームです。教材が公開されているので、興味を持たれた方はぜひ手を動かしてみてください。

Osaka Tech Labでは今後もイベント開催を予定しています。KINTOテクノロジーズのconnpassもあわせてチェックしていただけると嬉しいです。

参考リンク

• Claude Managed Agents Workshop（当日使用した教材）
• Claude Managed Agentsの概要（公式ドキュメント）
• Jina AI 公式MCPサーバー
• 社内でAIエージェント構築ワークショップを開催しました。（森田さんの記事）
• KINTOテクノロジーズOsaka Tech Labにご来場のかたへ

こんにちは、2026年5月入社のyaMayuです！

本記事では、2026年5月に入社したメンバー2名に入社直後の感想をお伺いし、まとめました。 KINTOテクノロジーズ（以下、KTC）に興味のある方、そして、今回参加してくださったメンバーへの振り返りとして有益なコンテンツになればいいなと思います！

Y.Q

• 自己紹介

  • グループコアシステム部　ビジネスディベロップメントGに配属されました。
  • 自動車部品メーカー→ITコンサル→当社　といったキャリアを歩んでいます。

• 所属チームの体制は？

  • グループコアシステム部の人数が多いですが、ビジネスディベロップメントGは割と少数精鋭です。（現在6人）
  • 同じグループのメンバーは出身地が多様で（欧州、北米、アジアetc.）グループ内の公用語は英語です。

• KTCの入社動機や入社前後のギャップは？

  • トヨタグループとしての安定感と、若い会社らしいベンチャーカルチャーの両方に魅力を感じたこと、またモビリティサービス領域でのビジネスディベロップメントに携わりたいと考えたことが入社の動機です。
  • 今のところ、大きなギャップは感じていません。

• 現場の雰囲気はどんな感じ？

  • 真面目な雰囲気とフラットな雰囲気の、良いバランスが取れていると感じます。

• オフィスで気に入っているところ

  • Water Serverがある。
  • 周りにランチできるお店が多い。（立地）

• yaMayuさんからの 質問：旅行が趣味とのことなので、おすすめの場所やまた行きたい場所があればお伺いしたいです！（日本国内でも、海外でもどちらでもOKです！）

  • 小笠原諸島です！片道1日ほどかかる長い船旅を経て訪れる分、非日常な体験が待っていました（ウミガメの産卵ツアーもおすすめです！）。太平洋に浮かぶ夜の星空や朝日にも感動し、また訪れたいと思っています。

yaMayu

• 自己紹介

  • プラットフォーム開発部 Quality Engineering GでQAエンジニアをやっています。
  • 異業種からSESに転職し、第三者検証を経てKTCに入社しました。
  • 京都市出身で今は都内在住、室町オフィス勤務です。
  • 趣味と呼べるものはあまりないですが、移動中はよくオーディオブックを聴いています。読書も好きです。ミステリー多めです。たまに映画を観に行ったりします。

• 所属チームの体制

  • Web QA, アプリQA, SETチーム合わせて21名です。
  • 6月にSETチームが新設され、大幅に人が増えました。
  • QA, SETチームとも室町オフィスとOsaka Tech Labにメンバーがいます。
  • 私はWeb QAチームに所属しています。

• 現場の雰囲気

  • 大阪のメンバーとは拠点が離れていますが、Slackやzoomで随時連絡や相談をしています。
  • オフィスに出社しているときは、一緒にランチ行くこともあり和やかな雰囲気だと思います。

• KTCへの入社動機や入社前後のギャップ

  • 前職、前々職ではお客様先のプロダクトに携わっていたので、自社プロダクトのQAに携わりたいと思い、転職しました。
  • プロダクトのジャンルはあまり絞っていなかったのですが、サブスクサービスはいろんなジャンルでどんどん広まっているので、今後も需要がありそう ＝ 多くの人に使ってもらえるプロダクトに携われそう、と思い入社しました。
  • カジュアル面談～面接～オファー面談でいろいろお話を聞くことができていたので、入社後の大きなギャップは今のところないです。

• オフィスで気に入っているところ

  • 地下鉄の駅から直結なので、雨でも濡れない＆日差しも怖くないところ。
  • 周辺においしいお店が多いところ。（お値段は安くはないですが…。）
  • フリードリンクでコーヒーが飲めるところ。

• Y.Qさんからの質問：京都出身者として、観光客があまり知らないおススメの場所や楽しみ方をご教示ください！

  • 最近はネットやSNSですぐ広まってしまうので難しいですね…笑
    • 志津屋のカルネ：もうすっかり有名になってしまいましたが、昔から好きで、今も実家に帰ると必ず食べます！
    • 法輪寺 電電宮：電気・電波の神様を祀る神社です。（日本唯一らしいです！）IT関連の人にも人気があります。嵐山にありますが、渡月橋から少し離れているので比較的空いていると思います。
    • 明智越：明智光秀が愛宕神社に参詣する際に通った道で、本能寺を攻める際にも通ったと言われています。今はハイキングコースになっていて、歴史と自然を感じられます。（台風や豪雨の影響で道が荒れている場合もあるようなので、訪れる際はご注意を。）

さいごに

みなさま、入社後の感想を教えてくださり、ありがとうございました！

KINTOテクノロジーズでは日々、新たなメンバーが増えています！ 今後もいろんな部署のいろんな方々の入社エントリが増えていきますので、楽しみにしていただけましたら幸いです。

そして、KINTOテクノロジーズでは、まだまださまざまな部署・職種で一緒に働ける仲間を募集しています！ 詳しくはこちらからご確認ください！

こんにちは、2026年4月入社の山本です！

本記事では、2026年4月入社メンバーに入社直後の感想をお伺いし、まとめてみました。 前の方からの質問に次の方が答えるリレー形式でお届けします。 KINTO テクノロジーズ（以下、KTC）に興味のある方、そして、今回参加下さったメンバーへの振り返りとして有益なコンテンツになればいいなと思います！

もっさん


• 自己紹介
  • KINTO開発部 開発推進Gに所属しています。
  • 案件全体の管理や、AIを活用したサイト構築のプロジェクトを担当しています。
  • スポーツ観戦が趣味で、最近は地元のBリーグクラブを応援しています。せっかくなのでKINTOと縁のあるアルバルク東京もこれから推していきたいです！
• 所属チームの体制は？
  • 開発推進Gは8名体制で、KINTOサービスに関わる開発案件のプロジェクトマネジメントを主に行っています。
  • 職種はPMが中心で、事業部側のメンバーや開発メンバーと連携しながら、ものづくりを進めています。
• KTCへ入社したときの第一印象は？ギャップはあった？
  • 前職の同僚が在籍していたこともあり、入社前から気軽に質問でき、カジュアル面談でも疑問をその場で解消できたので、不安なく入社できました。
  • 入社後はフットサルや筋トレなど、いろいろな活動を楽しんでいるアクティブな方が多く、いい意味でのギャップを感じました。
  • エンジニアの勉強会など学びや発信の場が多いのも印象的で、自分の経験がない分野でも興味があれば気軽に参加させてもらっています。
• 現場の雰囲気はどんな感じ？
  • 休憩室では豆を挽いてコーヒーを淹れている方がいて、香りにつられてふらふらと混ざりに行きました。とてもウェルカムな雰囲気で、業務でまだ関わりのない方ともゆるく繋がれるのがありがたいです。
  • 全員が中途採用ということもあり各分野のプロフェッショナルが揃っていて、日々の会話から多くの刺激をもらっています。
• オフィスで気に入っているところ
  • 室町オフィス勤務です。
  • オフィスから日本橋をわたって八重洲・銀座あたりを歩くのがお気に入りで、街のにぎわいを感じながらの散歩がいい気分転換になっています。
• 寿司と紅茶さん ⇒ もっさんへの質問

  生まれ変わったらなりたい職業とその理由を教えてください

  • 料理人やパティシエですね。今はチームでものづくりをしていますが、生まれ変わったら一人で黙々と何かを突き詰めてみたいです！

つじたく


• 自己紹介
  • 新サービス開発部 FACTORY EC開発G所属です。
  • 趣味は筋トレです。体を大きくしたいです。
• 所属チームの体制は？
  • 新サービス開発部 FACTORY EC開発Gで、TOYOTA/LEXUS UPGRADE FACTORYのEC基盤を開発・運用しています。
  • フロントエンド、バックエンド、PdM、SRE、QA、ディレクター、マネージャーなど合わせて15名ほどの体制です。
• KTCへ入社したときの第一印象は？ギャップはあった？
  • 入社前の面接の時も色々話をしていたので大きなギャップはなかったです！
• 現場の雰囲気はどんな感じ？
  • フロントエンド、バックエンド、PdMなど各方面のメンバーが揃っているので提案→実行までが素早くできて働きやすいです。
• オフィスで気に入っているところ
  • 駅から近く、改札出てから5分もたたずに自席に座れるところ。
  • オフィスが綺麗なところ。
• もっさん ⇒ つじたくさんへの質問

  TOYOTA UPGRADE FACTORY担当されていますが、こんなアップグレードあったらいいなと思うのはどんなものですか？

  • 自分の運転スタイルを学習して、燃費・快適性のバランスを自動最適化するAIモードみたいなアップグレードがあったらいいなと思います。

山本雄太


• 自己紹介
  • 新サービス開発部 プロジェクト推進グループ所属の山本雄太です。ロールはPjMです。
  • 仕事は寄り添い伴走するようなスタイルが性に合っており、誰かの為にだとより力が出るタイプ。
  • 趣味はゴルフ・釣り・サウナ・キャンプなどアクティブ系広め、お酒も大好きです。最近はゴルフにハマってます。やっと100を切りはじめました！
• 所属チームの体制は？
  • プロジェクト推進グループは10名にも満たない小規模体制ですが、トヨタグループ各社に対してKTCの技術力を活かして支援を主導するグループでもあり、やりがいは大きいです。
  • 最先端な取り組みにも関与できるチャンスがあるので、KTCの中でも一番面白いグループなのではとも思っています。
• KTCへ入社したときの第一印象は？ギャップはあった？
  • 第一印象は…オフィスがどの拠点も立派！笑
  • ギャップは想像以上にスキルフルなメンバーが多い点です。
• 現場の雰囲気はどんな感じ？
  • 少数チームという性質もあり、各自別のプロジェクトで作業しており実質的な関わりは少ないです。
  • ただ、定例MTGは情報交換が活発に行われており、相互に助言できる程よい雰囲気に感じます。
• オフィスで気に入っているところ
  • 私はFukuoka Tech Lab所属で、大名のリッツ・カールトンの真下にオフィスがあり景色が良い！博多湾を一望できて、天気が良い日には志賀島や能古島も綺麗に見える窓際がお気に入り、良いリフレッシュゾーンになっています。
• つじたくさん ⇒ 山本さんへの質問

  おすすめの日本酒教えてください！

  • 福岡は酒蔵が意外と多くて迷いますが、寒北斗をおすすめします！
  • 北斗七星をモチーフにしたパッケージやお猪口もあったり、見た目から愛せます。

寿司と紅茶


• 自己紹介
  • デジタル戦略部データグロースGでマネージャーをしています。
  • Webエンジニア → EM・PdM → 事業責任者 → VPoE といったキャリアを歩んでいます。
• 所属チームの体制は？
  • 1チームに機能横断している方々が揃っているのが特徴です。
  • PdM、エンジニア、デザイナーといったプロダクトトリオが揃っているため、多角的な視点から機能改善や案件進行ができるのが強みです。
• KTCへ入社したときの第一印象は？ギャップはあった？
  • リファラルなので事前に質問できていた点とカジュアル面談も複数回実施させていただいたため、ギャップはありませんでした。
• 現場の雰囲気はどんな感じ？
  • 比較的スタートアップのようにワイワイやっている雰囲気が強いですね。
  • 会社規模で考えると総合的に珍しいかもしれません。
• オフィスで気に入っているところ
  • フリードリンクが用意されているところ、宅配弁当が頼めるところですね。
• 山本さん ⇒ 寿司と紅茶さんへの質問

  これまでで一番歯ごたえのあった仕事はどんな仕事でしたか？

  • ゼロから開発組織を作ることになり、未経験から採用要件、スカウト業務、AG対応、カジュアル面談、面接、オファー対応などすべてやってました。

さいごに

みなさま、入社後の感想を教えてくださり、ありがとうございました！

KINTOテクノロジーズでは日々、新たなメンバーが増えています！ 今後もいろんな部署のいろんな方々の入社エントリが増えていきますので、楽しみにしていただけましたら幸いです。

そして、KINTOテクノロジーズでは、まだまださまざまな部署・職種で一緒に働ける仲間を募集しています！ 詳しくはこちらからご確認ください！

社内でAIエージェントの活用が進む中、ある部署から「AIエージェント開発に取り組みたいが、どこから始めていいかわからない」と相談をもらいました。座学だけでは手触り感が得られないので、実際に手を動かすワークショップ形式で開催することにしました。

弊社はAWSを主なクラウド基盤としているため、AWSが提供するAIエージェントの構築・運用基盤である Amazon Bedrock AgentCore と、エージェントのツール連携プロトコルである MCP（Model Context Protocol） を中心テーマに据えました。

教材として使用した書籍

ゼロから資料を作るよりも、体系的にまとまった書籍のハンズオンをベースにした方が、参加者が後から復習しやすいと考えました。今回は以下の2冊を使用しています。

• 『Amazon Bedrock AgentCore 実践入門 ── Strands Agentsで構築するAIエージェント』（SBクリエイティブ）　※以下、AgentCore本
• 『AWSではじめるMCP実践ガイド ── 基礎からAIエージェント構築まで徹底解説』（技術評論社）　※以下、MCP本

AgentCore本でエージェントフレームワークであるStrands AgentsやAgentCoreの各機能を学び、MCP本でMCPサーバーの自作とAgentCore Gatewayによるツール統合を学ぶ、という組み合わせです。

実は、どちらも私が共著者として執筆に携わった書籍です。手前味噌で恐縮なのですが、中身を隅々まで把握できている分、参加者がハンズオンで詰まったときにも補足しやすく、教材として選びました。

開発環境

今回は環境を揃えるため、GitHub Codespaces 上に開発環境を用意しました。書籍の手順をベースに、以下の工夫で環境構築にかかる時間を短縮しています。

• ツール管理は mise に統一し、mise use aws-cli node uv claude でAWS CLI・Node.js・uv・Claude Codeを一括導入
• AWSへは aws configure sso でSSOログイン
• コーディングのお供として Claude Code をセットアップ

サンプルコードは書籍著者が公開しているGitHubリポジトリを git clone して参照できるようにし、すべてのコードを手打ちしなくていいようにしました。

ワークショップの構成

1日のワークショップとして、午前・午後に分けて以下の流れで進めました。

午前の部（1.5時間）・・・Strands Agentsに触れる

午後の部（3時間）・・・AgentCoreとMCPを実践する

社内実施にあたって変更が必要だったポイント

書籍のハンズオンをそのまま社内で実施するにあたり、いくつか環境差異への対応が必要でした。

:::message メールアドレスのエイリアス 15章のアンビエントエージェントでは、サンプルデータ内の複数ユーザーのメールアドレスにそれぞれ通知を送る設計になっています。しかし社内のメール環境ではエイリアスが使えなかったため、data/users.json のメールアドレスをすべて自分のアドレスに統一しました。その結果、同じアドレスでSNSサブスクリプションが重複してしまうため、chapter15/cdk/lib/expense-agent-stack.ts で重複を排除するよう修正しました。

+ const uniqueEmails = [...new Set(emailAddresses)];
- emailAddresses.forEach((email, i) => {
+ uniqueEmails.forEach((email, i) => {
    // 各アドレスごとに SNS サブスクリプションを作成
  });

:::

:::message Googleカレンダー連携が使えない環境 13章のフルスタックエージェント構築ハンズオンはGoogleカレンダー連携（Google認証）を前提としているため、社内環境では実施が難しく割愛しました。興味がある方には自宅での実施を案内しています。 :::

:::message AWSアカウントの共有 複数人で1つのAWS環境を使ったため、リソース名が他の人と重複・混同しないよう、各自の名前を付与するルールにしました。特にS3バケット名はアカウント内で一意である必要があり、そのままだと衝突してしまいます。CDKスタックにハードコードされたバケット名（expense-agent-${account}）に自分の名前を付けて回避しました。AgentCoreランタイムも、agentcore create で付ける名前を handsonmorita のように各自で区別できるものにしています。 :::

:::message alert リージョンの差異 AgentCore本とMCP本で、使用リージョンが異なっているため、単一リージョンで実施するには読み替えが必要でした。GitHubで公開されているサンプルソースを利用して進めていたのですが、どこを修正すればよいかが見落としやすいポイントでした。 :::

参加者からもらった質問

ワークショップ中、参加者からいくつか印象的な質問がありました。

Q. ツールの定義はPythonでもできるのか？

Strands Agentsのツール定義はPythonのデコレータ@toolで行えます。関数のdocstringがそのままツールの説明文（description）としてLLMに渡されるため、Pythonで完結します。MCPサーバーとして公開する場合もPython SDKが利用可能です。

Q. Swarmエージェントはどうやってタスクを振り分けているのか？

マルチエージェント構成（Swarm）では、オーケストレーターとなるエージェントがLLMの判断に基づいて、各サブエージェントにタスクをルーティングします。各エージェントのnameやdescriptionに基づき、他のエージェントの役割を把握したうえで、作業を委譲するエージェントを選択します。

Q. マルチエージェントにするか、シングルエージェントにするか、どのように決めるのが良いか？

個人的な感覚としては、最初から厳密に切り分けようとしない方がうまくいきます。シングルエージェントとして作り始めて、複雑なタスクをうまく処理できなくなったり、コンテキストを分けた方が動きが安定すると感じた時点で、サブエージェントへの分割を考える、というのが実際の進め方に近いです。

Q. エージェントで使用するモデルはどのような基準で選んでいるのか？

コストを最初から意識しすぎないことが大事だと思っています。Sonnetをベースにまず作ってみて、判断の精度が足りない部分はOpusに切り替え、単純作業の部分だけHaikuでコストを下げる、という順番です。先にHaikuでコストを抑えようとすると、実現できる機能のレベルが下がってしまうので、まずは「エージェントとして実現できるか」を確認してから、コスト最適化に移る方がスムーズに進みます。

参加者の声

ワークショップの締めに参加者で「振り返り会」を行い、そこで出た声の中から印象的だったものをいくつか紹介します。

ある参加者は、「エージェントの動きが、これまでふんわりとマジックのように感じていたのに、こういう仕組みで動いていたのかと腹落ちした」と話してくれました。難しさの本質はプロンプトの作り込みにある、という気づきを得られたようです。

別の参加者は、ハーネスの手軽さに驚いたそうです。テンプレートに「あなたはプロ野球に詳しい人です」のような一行を書くだけでエージェントが動いてしまうのを見て、拍子抜けするほど単純だったと話していました。

MCPサーバーの自作に取り組んだ参加者は、午後の中でも特に難しかったと振り返っていました。それでも自分の手で実装したことで、普段使っているMCPの裏側の動きまで想像できるようになった、という言葉が印象的でした。

これまで固定パイプライン的な実装（情報を取得し、LLMに渡し、整形して出力する）に慣れていたという参加者は、エージェントが入力に応じて処理のルートを動的に決めていく発想自体が新鮮だったと語っていました。同じ入力でも出力のパスが事前に決まっていない、というところに面白さを感じたそうです。

ワークショップを終えて

1日にかなりの内容を詰め込んだこともあり、進み具合には個人差が出ました。午前の任意項目だったAgentCoreハーネス（5.2節）まで到達できた方もいれば、そこまで手が回らなかった方もいます。午後はそれぞれの興味に合わせて、アンビエントエージェントに取り組むグループとMCPサーバー構築に取り組むグループに分かれて進めてもらいました。

今回のワークショップを通して、書籍のハンズオンをベースにしたことで準備の負担を抑えつつ、実践的な内容を届けられたのは良かったです。本記事が、これから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エージェントを掛け算して、まずはたくさん転ぶところから。そして、転んで見つけた発見を、ぜひ組織に配ってください。

ここまで読んでいただき、ありがとうございました! あなたや周囲の人の発見が、組織の知恵になっていくことを願っています。

こんにちは。Engineering Officeのアクセシビリティアドボケート、辻勝利です。

6月のある朝、私は名古屋のあるビルの一室で、植木鉢を両手で抱え、聞こえてくる水の音を頼りに歩いていました。隣では竹中さんが猫の鳴き声を追いかけ、浜谷さんは焼き網の上で肉が焼ける音に、息を詰めて耳をすませています。三人が手にしていたのは、どれも映像のない、「音」だけで遊ぶゲームでした。

傍から見たら、なかなか不思議な大人三人組だったと思います。でもその場にいた私たちは、ただただ夢中でした。目で何かを確かめるのではなく、耳をすませて、音だけを頼りに遊ぶ。その新鮮さに、すっかり夢中になっていたのです。

私たちが訪れていたのは、「オーディオゲームセンター」という展示でした。映像ではなく「音」からゲームをつくり、音だけで遊ぶ——そんなユニークな作品が集まった場所です。名古屋で開かれていることを知り、出張のついでに同僚を誘って足を運んでみました。

制限時間内に、音だけを頼りに花へ水をあげる「はなちゃんを救え」。会場で最初に夢中になった作品です。

この記事では、その朝のことを書いてみたいと思います。

なぜ、この三人で行こうと思ったのか

少しだけ、前日の話をさせてください。私と竹中さんは名古屋で仕事があり、前日から出張していました。

せっかく名古屋まで足を運ぶのだから、この出張をアクセシビリティの活動にもつなげられないか——そう考えていたときに、ちょうどオーディオゲームセンターの展示が名古屋で開かれていることを知りました。アクセシビリティのアドボケートとして、これはぜひこの耳で確かめておきたい展示です。そう考えた私は、竹中さんに加えて、名古屋オフィスで働く浜谷さんにも声をかけました。浜谷さんは、ドライバーに向けたサウンド設計を仕事にされている方です。「音」を扱うプロと一緒に、音のゲームを体験できる。これ以上ない組み合わせだと思いました。

正直に打ち明けると、この「お誘い」には、私なりの小さな狙いもありました。

アクセシビリティのアドボケートとして、私が会社のなかで担いたい役割は、製品やサービスを使いやすくすることだけではありません。その手前にある、「アクセシビリティの文化」そのものを社内に少しずつ根づかせていくことだと考えています。

そのためには、ガイドラインやチェックリストと向き合う時間だけでなく、まだ見たこと・触れたことのない領域のアクセシビリティに、同僚たちが自然と出会えるきっかけをつくりたい。そんな思いが、以前からずっとありました。今回の展示は、そのきっかけにぴったりだと感じたのです。

「音」を共通言語にして遊んだ、あの日の記憶

この場所に同僚を連れて行きたかった理由は、もうひとつあります。それは、私自身の忘れられない原体験です。

ずいぶん前のことになりますが、私はかつて東京で、「オーディオゲームをつくるハッカソン」に参加したことがありました。視覚障害のある人も、目の見える人も、一緒になって音だけのゲームをつくり、その場で遊ぶ。そんなイベントでした。

そこで私が感じたのは、なんとも言えない心地よさでした。その場には、難しい「アクセシビリティ」の話は、ほとんど出てこなかったのです。「視覚障害者のために」とか「配慮しなければ」といった肩に力の入った言葉ではなく、ただ純粋に、「音を中心にしたゲームって面白いよね」という一点で人が集まっていました。

「音」という共通言語の前では、目が見えるかどうかは、その場の主役ではありませんでした。みんなが同じように耳をすませ、同じように戸惑い、同じように笑う。あの対等でフラットな空気が、私にはとても新鮮で、心地よかったのです。

この感覚を、ぜひ同僚にも味わってほしい。難しい理屈ではなく、まず「面白い」から入ってもらえる体験として——そう思ったことが、今回のお誘いの根っこにありました。

当日、私たちを夢中にさせた作品たち

さて、当日の会場には、いくつもの作品が展示されていました。どれも、思わず「お、これは!」と声が出てしまうような、ユニークなものばかりです。

1つめは、植木鉢を抱えて、音を頼りに水を探すゲーム。鉢を持って歩き回り、聞こえてくる音を手がかりに、水のありかを探し当てます。制限時間内に花へ十分なお水をあげられるかは、私たちの耳と方向感覚にかかっています。冒頭で私が抱えていたのが、この鉢でした。

2つめは、音だけで進行する人狼ゲーム。誰が人狼なのか、表情ではなく声と音だけで推理していく緊張感がありました。それぞれのプレーヤーには、小さなスピーカーを通して別々の振動が伝えられ、どんな振動が届いたのかを話し合いながら、誰が人狼なのかを推理していきます。自分に届いた振動のリズムを、そのまま声に出してしまわないよう気をつけながら、慎重に人狼を探しました。

声と音だけで人狼を推理する「サウンドウルフ」と、鳴き声から動物を当てるクイズ。プレーヤーには小さなスピーカーから別々の振動が届きます。

3つめは、猫の鳴き声を頼りに、迷路の中で猫を探して捕まえるゲーム。「ニャー」という声を追いかけて夢中になっている竹中さんの様子が、その声の弾み方から伝わってきて、なんとも微笑ましく感じました。見つけたと思った猫が、ふっと別の方向へ鳴きながら逃げていく。その手応えのなさに、私は昔飼っていたやんちゃな犬のことを思い出しました。

「Echolocation Maze ― 迷路でねこ探し」。アルミのフレームの中に入り、耳をすませて猫を探しているところ。目ではなく、音に集中する時間です。

4つめは、音を頼りに、ちょうどよい焼き加減を狙って焼肉を焼くゲーム。お肉が焼ける音の変化だけで、食べごろを見極める。サウンド設計を仕事にしている浜谷さんが、ここでいちばん真剣になっているのが、その張りつめた集中ぶりから伝わってきました。三人で同時にお肉を取り出すとボーナス点がもらえることもあって、それぞれが真剣にタイミングを見計らいながらゲームを進めました。

お肉が焼ける音の変化だけで、食べごろを見極める焼肉ゲーム。サウンド設計が本職の浜谷さんが、いちばん真剣に聞き入っていました。

そしてもうひとつ、ゲームというより、動かすと振動に合わせて笑い出す提灯のおもちゃもありました。手のなかで震えながら笑う提灯に、思わずこちらまで笑ってしまいました。子どもの頃に遊んだ「笑い袋」を思い出すような、ちょっと懐かしい作品です。

どの作品も、目で見て楽しむものではありません。耳をすませ、手で感じ、音の変化に身をゆだねて遊ぶ。気がつけば三人とも、すっかり童心に返って盛り上がっていました。

「面白い」が、いちばん最初にあっていい

会場を出たあと、私はふと、あの東京のハッカソンで感じた心地よさが、そのままここにもあったことに気づきました。

この朝、私たちは一度も、肩肘張った「アクセシビリティ」の話をしませんでした。ただ、音のゲームが面白くて、三人で笑い合っていただけです。目が見える二人と、見えない私とが、まったく同じスタートラインで戸惑い、同じように夢中になれる。そういう体験を、言葉ではなく、身体で分かち合えたことが、私にはとても嬉しかったのです。

アクセシビリティというテーマは、ともすると「正しさ」や「やらなければいけないこと」として語られがちです。それももちろん大切なことです。でも、その入り口に、こんなふうに「ただ純粋に面白い」という体験があってもいいはずだと、あらためて思いました。難しい話の前に、まず一緒に楽しんでしまう。そこから自然と、「音だけでこんなに遊べるんだ」「目に頼らない世界にも、こんな豊かさがあるんだ」という気づきが生まれていく。

これからも私は、社内のいろんな人と、こういう「触れるきっかけ」を少しずつ増やしていきたいと思っています。難しい顔で身構える前に、まず一緒に耳をすませて、笑ってしまう。アクセシビリティの文化は、案外そういう楽しい時間の積み重ねから根づいていくのかもしれない——名古屋出張の締めくくりに、そんなことを思ったのでした。

もうひとつの出会い ― 鼓動を伝えるモビリティ「QUENELLE」

会場には、オーディオゲームとは別に、もうひとつ強く印象に残った展示がありました。「QUENELLE（くねる）」という、小型EVのコンセプト作品です。

これは、乗る人の鼓動を読み取り、それを音や光、振動として映し出す乗り物でした。乗り物を「操作する道具」としてではなく、感覚でつながる相手のように感じさせてくれる——そんな試みです。私も実際にまたがらせてもらいました。

「QUENELLE」にまたがらせてもらいました。なお、同席されたスタッフの方など、ご本人の同意を確認できていない方のお顔は画像処理をしています。

鼓動を音・光・振動で映し出す、小型EVのコンセプト作品。乗り物を「操作する道具」から「ともにある存在」へと近づけようとする試みです。

ドライバーに向けたサウンド設計を仕事にする浜谷さんが、この作品の前で何を感じていたのか。それは、次の感想に譲りたいと思います。

一緒に行った二人から

最後に、同行してくれた二人に、当日の感想を一言ずつ書いてもらいました。

現地に行くまでは「音のゲーム」というものがまったく想像できず、どちらかといえば、見た目には地味で質素な作品をイメージしていました。でも、実際にプレーしてみると、自分自身が夢中になって遊んでしまうほど面白くて驚きました。子どもから大人まで、幅広い世代の人たちが一緒に楽しめる——オーディオゲームには、そんな可能性があると感じました。（竹中）

車を運転中のドライバーは、とても不自由です。ずっと前を見ていないといけないし、好きに動くこともできない。ほとんど唯一の愉しみは「音」ですが、音楽を流すか、ラジオを聴くか、同乗者とのお喋りか。それって数十年前からほとんど何も変わっていない。「音を愉しむ」って、もっと自由で、色んな可能性があるんじゃないか?と、ずっと考えていました。一緒に体験したオーディオゲームセンターの作品は、自分の中にあった漠然とした仮説を、確信へと一歩近づけてくれました。（浜谷）

目を使わずに「音」だけで遊ぶ時間は、私にとって、アクセシビリティの新しい入り口を確かめ直す時間でもありました。もし機会があれば、ぜひ一度、耳だけを頼りに遊んでみてください。きっと、思っているよりずっと豊かな世界が広がっています。

参考リンク

• オーディオゲームセンター: https://artscape.jp/exhibitions/64694/
• オーディオゲームをつくるハッカソン（CCBT）: https://ccbt.rekibun.or.jp/events/audiogamecenter_ccbt_hackathon

QEグループでモバイルチームに所属しているmです。 前職までは約7年ほどモバイルアプリの開発をメインに従事していました。 今はQAとしてプロダクト開発に関わっています。

この記事では、QAが設計や実装といった開発側との共通言語を持っておくと、テスト設計でも不具合対応でも有効である、という話を書きます。 共通言語があると問題の切り分けがしやすくなり、開発とのコミュニケーションコストも下がるため、本来集中すべき業務に工数を割きやすくなると考えています。

なお現在も対応中の取り組みなので、効果については「こう感じている」という話も含みます。

課題：内部の変更は、影響範囲が外から見えづらい

まず、この記事の出発点となる課題から整理します。

内部実装だけが変わる対応、特にユーザーから見える動作は変えないリファクタリングなどは、影響範囲が外から見えづらいという特徴があります。 例えば、Swift6対応やKMP対応、UIライブラリの移行などが該当するかと思います。 挙動レベルの影響は開発から共有されるものの、外から触っているだけではどこがどう変わったのかを把握しにくいです。

そのため、テスト設計では「影響範囲が分からないので、念のため全項目をテストしよう」となりやすく、 不具合対応では「ゼロから原因を探そう」という方向に傾きやすくなります。 ただ、実際には期日などの制約もあるため、すべてを見るわけにもいかない場合があります。

この「影響範囲が外から見えづらい」という点が、このあと述べる2つの工程（テスト設計と不具合対応）に共通する課題になります。

前提：アプリ側の設計・実装を把握して見る

課題への向き合い方として、まず普段行っている見方を記載します。

アプリは一枚岩ではなく、機能や役割ごとに分かれて作られています。 たとえば、画面の見た目を作る部分、データを加工する部分、サーバーと通信する部分、データを保存する部分、といった具合です。

何かが起きたとき、「画面上どう見えるか」だけで捉えるのではなく、 「それはどの責務の話なのか」「どことつながっているのか」を、アプリの作りの上で考えるようにしています。 これが、本記事で言う「構造から見る」という見方です。

たとえば「ログイン後の表示がたまにおかしい」という事象であれば、見た目を作る部分ではなく、 データを取得する通信や処理の部分が怪しいのではないか、と当たりをつける、といった具合です。

もちろん開発経験があるため、コードや設計資料を見れば、どの部分がどのように動き、どこにつながっているかは比較的把握しやすいほうだと思います。 ただ、この見方だけに頼るのではなく、開発側にも影響範囲の資料を展開していただいています。

そして、この見方がまず効くのが、テスト設計です。

テスト設計：見るべき範囲を、根拠を持って絞る

先ほどの「つい全項目をテストしたくなる」場面を、前項の考え方で設計します。

ここで行うのは、実装を隅々まで読むことではありません。「この変更は何をしようとしているのか」「だとすれば、何が壊れそうか」を、設計レベルで把握することです。 ここが分かると、何を見るか・どこまで見るかの手がかりになります。

具体的には、次の3つを問いとして使っています。

①動作は変わるのか、変えないはずなのか

変えないはずの変更であれば、見るべき軸は「変更前と同じか（同等性）」になります。見た目や操作感が、変更前と変わっていないかを確認する、ということです。

②技術的にどこへ影響のある変更なのか

並行処理なのか、UIの作りなのか、通信まわりなのか。 影響する領域が分かると、その領域で起きやすい問題が、見るべき観点になります。 たとえば並行処理が変わるのであれば、断続的に固まる・クラッシュする・反映が遅延する、といった点です。

③どの単位で入る変更なのか

画面単位なのか、モジュール単位なのか。これが分かると、見る範囲の単位が定まります。 たとえば、今回改修した画面のみを対象にする、といった具合です。

この3つの問いで根拠を持って絞れると、見る範囲が現実的なところに収まります。 「全部やる」から「変更によって壊れそうな箇所を確かめる」へ変わる、という感覚です。 あわせて、開発との「どこまで実施するか」のすり合わせも速くなると考えます。

後工程でも効く：不具合の起票と切り分け

ここまではテスト設計の話でしたが、メリットはその先の工程にも続くと考えています。

テスト設計の段階で把握した「この変更はどの実装箇所に影響があるか」という理解は、不具合の起票や切り分けの場面でも、そのまま活用できます。 一度読み込んだ作りが、ここでも改めて効いてくる、という形です。

そのため、案件にもよりますが、起票を見た時点で「このあたりが怪しいのではないか」と当たりをつけ、仮説つきで起票できます。 たとえば、表示崩れ・断続的に固まる、iOS・Android共通の不具合、といった切り口で、どの部分の話なのかを見立てられます。

重要なのは、これは「QAが原因を完璧に特定できる」という話ではない、ということです。 あくまで当たりをつけ、仮説を立てるところまでです。ただ、その仮説があるかないかで、その後の動きはかなり変わると考えています。

「画面が固まりました」とだけ書かれた起票と、 「ここは非同期処理の変更が入った画面なので、そのあたりが怪しいかもしれません」という仮説つきの起票とでは、 開発側が状況を把握する速さも、誰に依頼すべきかの的確さも変わってきます。 切り分けが、「ゼロから探す」から「仮説を検証する」へ変化し、開発とQA双方にとってメリットが生まれるかと思います。

実装に寄りすぎない

ひとつ、意識していることがあります。

現在の実装に寄りすぎると、「すでに実装されているもの」をなぞるだけになり、本来あるべきなのに、実装として抜けている観点を見落とすおそれがあります。 そのため、開発から共有された「本来こう動くべき」という挙動レベルの情報と、 コードや資料から読み取った「現状こうなっている」という状態を、突き合わせるようにしています。 構造理解で当たりをつけつつ、「ユーザーから見てどうあるべきか」という挙動ベースの視点も手放さない。 このバランスが大事だと考えます。

まとめ

今回の内容を要約すると、こうなります。

構造を理解しておくと、テスト設計でも後工程でも、QAの動きが「探す」から「検証する」へ変わる。一度の歩み寄りが、複数の工程で効いてくる。

もちろん、自身の背景などから知見があったという側面はありますが、それがないと無理な話ではないと考えています。 まずはプロジェクトのアーキテクチャ図や設計資料を読んでみる、詳細設計の境界を意識してみる、変更がどの設計箇所に影響するのかを開発に聞いてみる。 そうした小さなところからでも、見立ては変わってくるかと思います。

内部実装の変更で「全部見るしかない」となりがちな場面でも、構造から攻めることで、影響範囲の見立ての精度を上げられます。 同じような場面に立っている方の参考になれば嬉しいです。

弊社では Claude Code を全社的に導入しており、Claude Code のメトリクスとログを OpenTelemetry で収集し、Grafana で可視化しています。ところがある日、こんな声が飛んできました。

「ダッシュボード、また固まってるんだけど」

社内に Claude Code を展開して、いざ「みんなどれくらい使ってる？」を可視化しようとしたら、開いたダッシュボードがくるくる回り続けて何も出てこない。タイムアウト。リロードしてもまた回る。

原因は Claude Code が吐く 1 つのメトリクス claude_code_token_usage_tokens_total でした。これがカーディナリティ爆発（カーディナリティについては後述）を起こして、Thanos Query のメモリで使い倒していました。

この記事は、その障害を Grafana Managed Recording Rule × Prometheus × Thanos の構成でどう捌いたか、の記録です。打ち手を 3 案で比較した話と、採用案で実際にハマった「書き込み先（write 先）問題」を 2 段階でほどいた話がメインです。同じように AI ツールの利用状況を可視化したい人、そして高カーディナリティに殴られた経験のある Observability 担当者の参考になればと思います。

:::message この記事の構成は「検証で動作確認し、現在は短縮稼働で運用している」段階のものです。本番フル稼働の数値ではなく、構成判断のプロセスと再現できる設計を中心にまとめています。 :::

1. 何が起きていたか：claude_code_token_usage_tokens_total のカーディナリティ爆発

Claude Code は OpenTelemetry 経由でトークン使用量などのメトリクスを出力できます。その中心が claude_code_token_usage_tokens_total です。

問題はラベルでした。このメトリクスには session_id が付きます。セッションごとにユニークな ID が振られるので、利用が増えれば増えるほど系列（time series）が線形に増え続ける。さらに user_email、model、type（input/output/cacheRead など）も掛け算で効いてくる。

claude_code_token_usage_tokens_total{
  session_id="...",      # ← セッションごとにユニーク。爆発の主犯
  user_email="...",
  model="claude-...",
  type="output"
}

:::details カーディナリティとは メトリクスにおけるカーディナリティとは、あるラベルが取りうる値の種類数のことです。たとえば type ラベルの値が input・output・cacheRead の 3 種類しか振られなければカーディナリティは低い。一方 session_id のようにセッションごとに異なる値が振られるラベルは、セッションが増えるほど無限に種類が増えていく「高カーディナリティ」なラベルです。ラベルの組み合わせが時系列（time series）の数になるため、高カーディナリティなラベルが 1 つあるだけで系列数が爆発的に膨れ上がります。 :::

session_id のような無限に増える値（unbounded label）が 1 つ混じるだけで、系列数は天井知らずになります。

そして Thanos Query は、クエリ時に対象系列をメモリ上に展開してから集計します。系列が数十万を超えてくると、sum by (user_email) のような一見シンプルな集計でもメモリを食い尽くし、タイムアウトか OOM で落ちる。ダッシュボードが固まっていた正体はこれでした。

2. KTC のモニタリング基盤の構成

本題に入る前に、今回の話に登場するコンポーネントを整理します。

2-1. Alloy（OpenTelemetry Collector）

Grafana Alloy は OpenTelemetry ベースのコレクターです。KTC では各システムの AWS サービスのログやClaude Code からメトリクス・ログを収集する入口として機能しています。

2-2. Prometheus

Kubernetes 上のメトリクスを scrape する OSS の監視ツールです。KTC では scrape したメトリクスを Thanos Receiver への remote write で転送するリレー役を担っています。メトリクスの長期保存は Thanos に委ねる構成です。

2-3. Thanos

Prometheus をスケールアウト・長期保存対応させるための OSS です。KTC では以下のコンポーネントで構成しています。

マルチテナント構成を採用しており、書き込み時は通常 THANOS-TENANT HTTP ヘッダーでテナントを指定します。

2-4. Grafana

Grafana は Thanos をデータソースとして接続し、ダッシュボードの描画と Recording Rule の管理を担います。KTC ではシステム単位でマルチテナント化した Grafana インスタンスを各チームに払い出しており、今回 Claude Code コスト可視化用に専用インスタンスを立ち上げました。

3. 課題とゴール

「じゃあ session_id を消せば終わりでは？」と思いますよね。でもそれが簡単に言えない理由がありました。

社内で AI 活用を進めるには、まず測れることが前提になります。誰がどれくらい使っているのか、どのモデルにトークンが寄っているのか、1 セッションあたりの規模感はどうか。こういう粒度がないと「活用が進んでいるのか」を語れない。

特に session_id 単位の分析は、後から「効果的な使い方をしているチームの傾向を見たい」みたいな分析に効いてきます。つまり生データとしての session_id は手元に残したい。でもダッシュボードのクエリでそのまま頑張るのは無理。この二つを両立させるのが今回のお題でした。

ゴールはこう整理できます。

• 生データ（session_id 付き）は Thanos に貯め続ける
• ダッシュボードは「集約済みの軽いメトリクス」を見る
• 利用者がセルフサービスで見たい情報を見れるように調整ができること

4. 案比較

カーディナリティへの対象策はいくつかあります。今回は 3 案を並べて比較しました。

判断の軸は 2 つでした。

1. 生データを失わないか（session_id を残せるか）
2. ルールを誰が育てられるか（利用者が回せるか）

案1 は軸1で不採用。収集段階で捨てるとデータ分析に利用できません。案2 は軸2で不採用。Thanos Ruler はサーバ側のルールファイルを Platform が管理する世界なので、「ちょっとこの集約を試したい」が毎回 Platform への依頼になってしまう。これは Platform チームのボトルネック化も招きます。

残った案3 が、両方の軸をクリアしました。

5. Remote Write 先問題を 2 段階で解いた

案3 を進める上でも課題がありました。Grafana Managed Recording Rule は「集約した結果をどこかに書き戻す」必要があります。メトリクスの管理に使っているThanosの場合はここがうまく設定できませんでした。

5-1. 詰まり1: Datasource に Thanos Receiver を直接指定できない

Thanosにおいて、メトリクスの書き込み先は Thanos Receiver であるので、 Grafana の Datasource で Thanos Receiver を指定することを考えました。

ところが Datasource として登録できませんでした。理由はこうです。

• Grafana の Datasource は基本的に Query（読み取り）系に対して作るもの
• Thanos Receiver は Write 専用で、Query を受け付けられない
• だから Receiver は Datasource として成立しない

ここで再検討した結果、既に別用途で使用していた Prometheus でした。Prometheus は Query も Write（remote write 受信）も両方できる。そこで Prometheus を Grafana の Datasource として指定することにしました。

• Grafana の Datasource → Prometheus（Query を受け付けらるので Datasource になれる）
• Recording Rule の書き戻し → Prometheus の /api/v1/write で受ける(※)
• Prometheus が remote write で Thanos Receiver へ流す

という形にしました。Prometheus が「Query 窓口」と「Write の中継」を兼ねることで、Datasource 問題が解けました。

※ Prometheusはデフォルト設定では、Queryを受け付けられないので --web.enable-remote-write-receiver フラグを有効にし、外部から /api/v1/write でメトリクスを受け付けられる** にしています。

5-2. 詰まり2: マルチテナントへの書き込み（HTTP ヘッダーを操作できない）

次の壁はマルチテナントでした。Thanos Receiver はテナントを分けて受け取れますが、その振り分けは通常 HTTP ヘッダー（THANOS-TENANT） で指定します。

ところが Grafana Managed Recording Rule の設定項目には、書き戻し時の HTTP ヘッダーを差し込む設定がありません。ルールの式と書き戻し先は指定できても、ヘッダーは触れない。AI 活用用のテナントへ正しく振り分けたいのに、その手段が塞がれている状態でした。

解決には Thanos Receiver 側の機能を使いました。

thanos receive \
  --receive.split-tenant-label-name="tenant_id"

--receive.split-tenant-label-name を指定すると、Receiver は HTTP ヘッダーではなくメトリクスのラベル値を見てテナントを振り分けてくれます。つまり、

• Recording Rule の集約結果に THANOS-TENANT="ai-usage" のようなラベルを付けておく
• Receiver がそのラベルを読んで AI 活用用のテナントへ流し込む

ヘッダーが操作できないなら、振り分けの判断材料をラベルに寄せる。発想を「ヘッダーで指定する」から「ラベルで宣言する」に切り替えたのがポイントでした。

5-3. 全体アーキテクチャ

2 つの詰まりを解いた結果、データの流れはこうなりました。まず全体像を俯瞰します。

ポイントをまとめると：

• Prometheus が二役：Grafana からの write を受け取る --web.enable-remote-write-receiver と、Thanos への転送（remote_write）を同時に担う
• テナント振り分けはラベルベース：Routing Receiver の --receive.split-tenant-label-name=THANOS-TENANT により、Recording Rule で付けた THANOS-TENANT ラベルの値でテナントが決まる。HTTP ヘッダーを操作できない制約をラベルで回避した

6. Before / After：タイムアウトが消えた

検証段階での効果はシンプルです。

ダッシュボードが普通に開く、という当たり前を取り戻しつつ、生データも分析の主権も手放さずに済んだ、というのが今回のゴールでした。

7. まとめ

今回やったことを、次に同じ状況に出会った人が調査・検討できる粒度で残しておきます。

• 無限増殖するラベル（session_id 等）はカーディナリティ爆発の主犯。
• 生データを収集段階で捨てる前に「後の分析で使うか」を問う。Alloy でのドロップは確実だが取り返しがつかない
• Thanos Receiver は Write 専用なので Datasource にできない。Query も Write もできる Prometheus を中継に挟む
• Grafana Managed Recording Rule は書き戻し時に HTTP ヘッダーを操作できない。テナント振り分けは --receive.split-tenant-label-name でラベルベースに寄せる

ここまで読んでいただきありがとうございました！

こんにちは、KINTOテクノロジーズ（以下、KTC）のQuality Engineering グループでQAエンジニアをしているろきです。

本記事では、マインドマップを使った観点作成の導入経緯、実際の使い方、そして運用を通じて見えてきたことをお伝えします。

マインドマップを試すことになった経緯

現在、QAチームでは観点をConfluenceのページで作成しており、画面単位ではなくテストの目的別（機能確認・表示確認・バリデーションなど）にページを作成し、箇条書きやテーブルで管理しています。 テストの目的別で観点を作成すると同一画面の観点が複数ページに分散するため、全体を一覧で見渡したいと感じる場面がありました。 そこで、1つのボードでQA対象範囲全体の観点を俯瞰できるマインドマップの活用を提案し、試験的に導入することになりました。

マインドマップの作成ルールと構造

ツールを導入するにあたり、作成ルールを統一しました。

使用ツール

マインドマップはMiroを使用しています。

基本構造

マインドマップは以下の階層構造で作成しています。

案件名_verX.X.X > 画面/機能 > 観点 > 因子 > 水準 > 期待値

何をマインドマップにするか

現在、KTCのQAチームでは、テスト観点を主に以下の5つに分類して作成しています。

• シナリオ
• 機能確認
• 表示確認
• バリデーション
• アドホック

このうち、マインドマップ化の対象としているのは主に以下の3つです。

• 機能確認
• 表示確認
• バリデーション

表示確認やバリデーションはConfluenceでリスト化して管理しているため、テスト対象ごとに「表示確認を参照」「バリデーションを参照」のように参照先を記載し、黄色のマーカーで色分けするルールにしています。こうすることで機能確認の観点との区分けがはっきりし、どの対象をどの観点で確認するかを過不足なく整理できます。

一方、シナリオテストやアドホックテストの観点はマインドマップにしません。 これらは、機能確認などと比べるとマインドマップで構造化して整理する必要性が低いため、従来通りConfluenceで文章形式のものを使用する運用としています。

使ってみてわかったメリット

テスト対象の観点を1か所で把握できる

マインドマップ導入における最大のメリットは、1つの画面/機能に関するすべてのテスト観点を1か所で把握できる点でした。

従来のドキュメント形式では観点の種類ごとにページが分かれているため、「この操作はどの観点で確認するのか」を複数ページにまたがって探す必要がありました。マインドマップでは画面/機能を起点に観点が集約されるため、作成時に「各テスト対象にどの観点が紐づいているか」をリアルタイムで確認しながら進めることができます。結果として、テスト対象物と観点の対応関係における過不足を発見し、修正しやすくなりました。

マインドマップがそのままテスト設計の「下書き」に

マインドマップは観点から因子・水準へと枝を広げていく構造上、「通知ON/通知OFF」「入力あり/なし」といった条件分岐を自然に書き出せます。具体的な条件分岐まで落とし込めるため、観点とテスト設計を同時に整理できるようになりました。

条件分岐を書くことで、観点と仕様の精度が上がる

条件分岐を書き出す過程で「この条件の場合の仕様が書かれていない」と気づくケースも増えました。観点作成の段階で仕様の抜け漏れを発見できるため、開発チームやPMへの仕様に関する質問や、仕様書レビューをスムーズに進めやすくなりました。

さらに、「ログイン済み/未ログイン」のように対になる条件が枝として横並びになるため、片方だけ記載されていないケースが視覚的にわかりやすくなります。ある観点の枝だけが極端に少ない・多いといったアンバランスも視覚的に気づきやすく、観点の粒度を揃えやすくなりました。

議論が活発になり、認識合わせに有用

これは導入前には想定していなかったことですが、マインドマップを開発チームとの認識合わせの場で使うと、議論がより活発になりました。視覚的に構造が見えることで「この条件でもテストしてほしい」「この枝はカバレッジが高いので減らしてもいいのでは」といった具体的なフィードバックが出やすくなり、認識合わせに有効でした。

見えてきた課題

Confluenceとの連携

MiroボードをConfluenceに埋め込む際、現状では画面/機能単位で特定範囲だけを埋め込むことができず、ボード全体が表示されてしまいます。画面/機能ごとにピンポイントで埋め込めるようになると、Confluenceとの連携がより使いやすくなると感じています。

コスト

現在はトライアルとして数人のみ契約していますが、チーム全体での利用が本格化する場合はコストが増加します。ボードの作成/編集には契約アカウントが必要ですが、ゲストアカウントであれば閲覧やコメント追加ができるため、用途に応じて使い分けていければと思っています。

まとめ

Confluenceと併用したマインドマップの導入は、テスト観点の具体化・可視化という点で大きな効果がありました。特に「観点が自然と具体的になる」「議論が活発になる」という副次効果は、設計品質向上に貢献していると感じています。

一方で、Confluence連携やコストといった課題も見えてきました。

まずは無料プランで気軽に試せるツールなので、「テスト観点の整理がうまくいかない」と感じているQAチームにはぜひ一度試していただきたいと思います。