こんにちは、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チームにはぜひ一度試していただきたいと思います。

SeleniumConf & AppiumConfとは

ブラウザ自動化・モバイル自動化のコミュニティを世界中から集める国際カンファレンスです。

• Software Freedom Conservancyが運営しており、SeleniumおよびAppiumのコアコントリビューターも登壇します。
• Selenium 5に関する今後の展望、WebDriver BiDi、Appium、Playwright、Cypress、AIテスト、セキュリティテスト、アクセシビリティテストなど、幅広いテーマを扱っています。
• 基調講演・ハンズオンワークショップ・ネットワーキングの3つの形式で構成されています。
• 全セッションに英語字幕とスペイン語通訳が提供されるなど、グローバルな参加者を意識した運営が特徴です。
• 今年は 2026年5月6日〜5月8日 にスペインのバレンシア・Veles e Ventsにて開催され、20カ国以上から約350名が参加しました。
• 1日目はハンズオンワークショップ、2〜3日目がカンファレンス本番という構成でした。

https://seleniumconf.com/

今回、KINTOテクノロジーズから呂文佳とパンヌウェイの2名が登壇しました。世界の舞台でKINTOテクノロジーズの取り組みを発信できた、非常に貴重な機会となりました。

バレンシアまでの道のり

CfPの告知から登壇当日まで、約8ヶ月の期間がありました。最初のきっかけは2025年9月、会社の同僚が社内SlackチャンネルでCfP（Call for Proposals）開始を告知してくれたことです。「ぜひ挑戦してみてください！」というその一言が、すべての始まりでした。

:::details 承認・ビザ手続きについて CfP当選後は社内手続きも必要でした。社長に登壇内容を説明して承認をもらい、その後カンファレンスチームとメールでやり取りしながらビザ申請の手続きを並行して進めました。国際カンファレンスへの参加には、こうした社内外の調整も大切な準備の一部です。 :::

参加セッション一覧

2026/05/06（1日目）：ワークショップ

1日目はカンファレンス本番前のワークショップデーです。終日1つのセッションに集中して参加しました。

Making Sense of Mobile Automation with Appium and WebdriverIO

登壇者

• Wim Selles — 2025 Tokyo Test Festにも参加した方
• Christian Bromann

内容と学び

このワークショップでは、Appiumをゼロからインストールして2分以内にセットアップが完了することを実際に確認しました。セットアップの簡単さを体感できたことで、導入ハードルへの認識が変わりました。

ワークショップ後、登壇者のWim Sellesさんと直接Appiumについて相談する機会も得ました。特に「要素特定にIDを使うかXPathを使うか」という実務的なテーマについて深く議論し、それぞれのメリット・デメリットを理解することができました。

• ID： 高速・安定だが、開発側でIDが付与されていない場合は使えない
• XPath： 柔軟性が高いが、UI変更に弱くFlaky Testの原因になりやすい

:::details ディナーでの交流（1日目夜） 1日目の夜はカンファレンス関係者とのディナーがあり、非常に充実した交流の場となりました。

• Kazuaki Matsuoさんと同席し、Appiumの導入経験や現場の課題について情報交換をしました。
• Oscar Barriosさん（昨年も登壇された方）とは今年のイベントの印象やコミュニティの動向についてお話ししました。
• Ivan del Visoさん（昨年も登壇された方）は、ご自身が開発したアプリを使った自動化テストのデモを見せてくれました。英語で1行のテストシナリオを書くだけで、実行・分析・ダッシュボードレポートの生成まですべてが完結するシステムで、非常に印象的でした。 :::

2026/05/07（2日目）：カンファレンス本番

2日目からいよいよカンファレンス本番です。複数のトラックが並行して開催され、関心のあるセッションを選びながら参加しました。

セッション①：Quantum Automation — AI時代のSelenium & Appium

Quantum Automation: Rethinking Selenium & Appium in the Age of AI（登壇者：Baris Sarialioglu）

AI時代における自動化テストの在り方を問い直す内容でした。セッション中に聴衆から質問が上がった場面では、登壇者が次のように答えたのが印象に残っています。

セッション②：呂さんの発表（11:20〜40分）

From 50% Cost Reduction to 90% Coverage: Playwright × AI for Non-Technical QA Teams

KINTOテクノロジーズの同僚・呂文佳さんによる発表です。コーディング経験が浅いQAメンバーでもPlaywright × AIを活用することでテストカバレッジを大幅に向上させた実践事例を紹介しました。同じチームのメンバーが国際カンファレンスで発表する姿は、大きな刺激になりました。

セッション③：Test Automation Workflows with Cursor（13:20〜90分）

Test Automation Workflows with Cursor

登壇者：Filip Hric

Cursor（AI統合コードエディタ）を活用したテスト自動化ワークフローについて90分間フルで講演されました。ClaudeとGitHub Copilotの基本的な設定・活用方法がメインテーマで、Mobile QAで一緒に作業している岡さんに教えていただいた内容とほぼ同じでした。世界のカンファレンスでも同様のアプローチが注目されていると確認できたことは収穫でした。

この日のセッション終了後、翌日に控えた自分の発表準備のためホテルへ戻り、最終調整を行いました。

2026/05/08（3日目）：自分の発表

いよいよ自分の登壇日です。朝から会場でスライドの確認と発音練習を行いました。

発表概要

なぜCfPが採択されたのか

:::message 国際カンファレンスで登壇できることは非常に光栄なこと。世界中のテストエンジニアが集まる場でKINTOテクノロジーズの取り組みを発信できる貴重な機会です。 :::

今回、採択につながったポイントは、単なる成功事例の紹介ではなく現場で直面した課題と改善の過程を正直に共有した点にあると考えています。

• 実際に直面した課題と、改善によって得られた成果を正直に共有したこと（理想論ではなく現場の実態）
• 具体的な数値で課題を提示：128件のテスト実行に12時間かかっていたという課題を可視化
• Claude・Copilot・DevinAI の実践的な活用方法と3ツールの比較
• 聴衆が持ち帰ってすぐに実践できるチェックリストを提供したこと

発表構成（45分）

当日の会場の様子と反響

20カ国以上から参加者が集まる満席の会場での登壇でした。発表後の質疑応答では予想以上に多くの質問が集まりました。

• ドイツ在住のパキスタン出身のエンジニアから、Appiumの社内導入に関する具体的な質問を多数いただきました。自分たちのチームでも同様の課題を抱えており、ぜひ参考にしたいとのことでした。
• 複数の参加者から「自分たちの導入方法の参考になった」と直接声をかけていただきました。

発表がただの情報共有にとどまらず、世界中のエンジニアの実務に役立ったと感じることができ、大変嬉しかったです。

スポンサー企業との交流と自動化テストツールの調査

カンファレンスにはテスト自動化ツールのスポンサー企業がブースを設けており、担当者から直接、各ツールの詳細を聞く貴重な機会がありました。ここでは、カンファレンスの場で実際に収集した情報をもとに、4つのツールを比較・整理します。

各ツールの概要

機能比較マトリクス

凡例：◎ 優秀　○ 良好　△ 要改善

各ツールの詳細印象

:::details CloudBeat 強み

• コードレステストが充実しており、プログラミング経験がなくてもテスト作成・実行が可能
• Selenium・Appium・Cypress・Playwright等の主要フレームワークと幅広く統合
• AIドリブンなテストレポートで根本原因分析（Root Cause Analysis）が容易
• テスト実行・管理・モニタリングをすべて1プラットフォームで完結できる

弱み

• モバイルアプリテスト（ネイティブアプリ）の対応デバイス数がBrowserStackなどに比べて少ない
• 英語のみの対応で、日本語UIや日本語サポートが提供されていない
• 他ツールと比べると国内での導入事例や公開情報が少なく、長期利用を前提とする場合は追加調査が必要 :::

:::details Sauce Labs 強み

• 長年の実績を持つエンタープライズ向けプラットフォーム。信頼性・安定性が高い
• SOC2 Type II・GDPR・ISO 27001等のセキュリティ・コンプライアンス認証を取得
• Webテストもモバイルアプリテストもどちらもカバーできるオールラウンダー

弱み

• 今回確認した条件では4ツールの中でも価格面の負担が大きく、中小チームや予算が限られた組織には慎重な検討が必要
• コードレステスト機能が弱く、プログラミングスキルがないメンバーには難易度が高い
• 一部CI/CDツール（AWS CodePipeline・GitLab CI等）に非対応 :::

:::details BrowserStack 強み

• 実機デバイス数・ブラウザ組み合わせ数が業界最多水準（30,000台以上）で、網羅的なテストが可能
• Accessibility Testing・Percy Visual Testingなど高度な付加機能が充実
• カスタマーサポートの評判が良く、ドキュメントが整備されている

弱み

• 料金が高額で、コスト面での負担が大きい
• 基本的にSelenium/Appium等の自動化スクリプト記述が必要で、非エンジニアには敷居が高い
• ネットワーク遅延や実機テストでの偽陽性（誤検知）が報告されることがある :::

:::details LambdaTest（現 TestMu AI） 強み

• KaneAIにより、自然言語でテストケースを記述するだけでスクリプトが自動生成される
• 今回比較した条件では、4ツールの中でもコストパフォーマンスが高いと感じた
• Jenkins・GitLab CI・Azure Pipelines・AWS CodePipelineを含む幅広いCI/CDツールに対応
• HyperExecuteによる超高速な並列テスト実行が可能

弱み

• 実機デバイスの実際の可用性がBrowserStackに比べると劣る場合がある
• テスト分析レポートの詳細度が競合より低く、根本原因分析に限界がある
• UIのナビゲーションが複雑で、習熟に学習コストがかかる :::

総合評価と推奨

現状のチーム状況（非エンジニアメンバーでも扱いやすいこと、Web・モバイルアプリの両方に対応できること）を踏まえた評価です。

感想・学び

海外カンファレンスならではの気づき

:::message 現地ではコミュニケーション手段としてLinkedInが主流で、名刺交換の機会はあまり多くありませんでした。 現地で知り合った方とは、LinkedInで連絡先を交換しました。海外エンジニアとのつながりを作る際は、事前にLinkedInのプロフィールを整えておくことをおすすめします。 :::

現地での交流から得た、世界のQA事情についての気づきも多くありました。

• 開発とQAを兼務しているエンジニアが多い — 日本のように専任QAチームが分離している体制は珍しく、開発者自身がテストも担う形が世界的には一般的なようです
• ノーコードの自動化ツールを利用している人は少数派 — コードを書いてテストを自動化するスタイルが主流で、ノーコードツール利用者は少数派という印象でした

自動化テストの現状と課題

:::message alert 世界のAppiumユーザーの声：「自動化テストをやめるべきか考えている」という方もいました。 理由は Flaky Test（不安定なテスト）の問題です。今回成功しても次回失敗する、という繰り返しによって、テスト自動化そのものへの信頼が揺らぐケースが世界的にも多いようです。 :::

Flaky Testは自動化テストにおけるグローバルな課題であり、その解消こそが現代のテストエンジニアに求められていることを、改めて実感しました。AIツールを活用した根本原因分析や、要素特定用のIDを活用した安定したテスト設計が、この問題への有効なアプローチとなるでしょう。

まとめ

約8ヶ月の準備を経てバレンシアの国際舞台に立ち、世界中のエンジニアとKINTOテクノロジーズの取り組みを共有できたことは、自分にとって大きな経験となりました。セッションで得た知識・現地での人脈・ツール各社との情報交換、そして自分の発表への反響——すべてが今後の業務に活きる財産です。来年のSeleniumConfにも引き続き注目していきたいと思います。

1. はじめに

Quality Engineering Gのとみよしです。

私が所属するQAチームではオープンソースのテスト管理ツールであるTestLinkを採用しています。

:::message TestLinkとは テストケースの作成・管理からテスト計画の立案、実行結果の記録まで一元管理できるオープンソースのテスト管理ツールです。 :::

TestLinkへの結果入力は工数がかかるため、Excelマクロで結果を一括入力できるXMLファイルを生成する仕組みを運用していました。

しかしこのExcelマクロには2つの課題がありました。

• チーム内にMac・Windowsユーザーが混在しており、OS差分を考慮した2本のコードを管理しなければならなかった
• ローカル環境でのみ動作するため、更新のたびにファイル共有が必要だった

これらを解決するために、Microsoft 365のCopilotを活用してGoogle Apps ScriptでWebアプリを作ってみました。コードは一行も自分で書いていません。 その過程を紹介します。

2. 解決策としてGAS Webアプリを選んだ理由

課題の本質は「環境に依存している」ことでした。ブラウザで動くWebアプリにすれば、OSの違いもローカル管理の問題も一度に解決できます。

その中でGAS（Google Apps Script）を選んだ理由は主に3つです。

① OS差分がなくなる ブラウザで動くため、MacでもWindowsでも同じように使えます。

② Google スプレッドシート（以下、GSSと表記）と連携できる プロジェクトコードや担当者などのマスタデータをGSSで管理し、Webアプリからそのまま参照できます。更新もGSS上で行うだけなので、誰でもマスタ更新が可能になります。

③ 無料で使える Google アカウントがあれば追加コストなしで開発・運用できます。

3. 完成したWebアプリの紹介

主な機能は3つです。

① 一括生成 テストケースが連番になっている場合に使います。開始番号と終了番号を入力するだけで、その範囲をまとめたXMLファイルを出力できます。 例）No.1〜100をまとめて一括出力

② 個別生成 テストケースを個別に指定して出力します。飛び番号のケースや、特定のケースだけ再テストしたい場合に便利です。 例）No.1, 3, 5, 7, 10を個別に出力

③ マスタ管理 プロジェクトコードや担当者名をGSSで管理しています。画面右上の「マスタを編集」ボタンからGSSに直接遷移して編集できます。

4. 開発の進め方 〜Copilotと約15往復した話〜

「WebアプリはGASで作ろう」と決めたものの、私は簡単なGASのコードしか書けず、Webアプリに関する知識はほとんどありませんでした。そこで活用したのがMicrosoft 365のCopilotです。

Copilotへの最初の一手

まず既存のExcelマクロのコードをそのままCopilotに貼り付け、以下のように依頼しました。

「このExcelマクロと同じ機能をGAS（Google Apps Script）で書いてください」

たったこれだけです。Copilotは既存コードの意図を読み取り、GAS向けのコードを出力してくれました。Excelマクロという既存の資産がそのまま設計書代わりになったわけです。

機能を1つずつ育てていった

最初から全機能を一度に作ろうとせず、以下の順番で1つずつ機能を追加していきました。

1. 一括生成機能の作成
2. 個別生成機能の追加
3. マスタ機能の追加
4. 細かい仕様の追加
5. Webアプリ化

1ステップずつCopilotに依頼し、動作を確認してから次に進む流れです。結果的に10〜20往復のやり取りになりました。

エラーが出たらそのまま貼り付ける

開発中にエラーが発生することも何度かありましたが、対処法はシンプルです。

エラーメッセージをそのままCopilotに貼り付ける

それだけで原因の説明と修正コードを返してくれました。エラー対応は1〜2往復で解消できました。

5. やってみて気づいたこと

Copilotへの伝え方のコツ

一度に複数のことを依頼するより、1つの依頼につき1つの機能追加に絞ったほうがスムーズでした。欲張って「あれもこれも」と依頼すると、意図が伝わりにくくなることがありました。

QAエンジニアでもWebアプリが作れた

着手前は「自分にWebアプリなんて作れるのか」という不安がありました。しかしCopilotに既存のコードを渡してやり取りを繰り返すだけで、気づけば動くWebアプリができあがっていました。

プログラミングの専門知識がなくても、「何をしたいか」を言葉で伝える力があれば十分です。

Before / After

「はじめに」で挙げた2つの課題が、どちらもきれいに解消されました。

6. おわりに

「QAエンジニアにはコードが書けない」なんてことはありません。

AIを活用すれば、既存の資産を渡すだけで新しい環境向けのコードを生成してもらえます。 私自身、コードを一行も書かずにWebアプリを完成させることができました。

同じようにExcelマクロの管理に悩んでいるQAエンジニアの方がいれば、ぜひ一度試してみてください。まず手元にあるマクロのコードをCopilotに貼り付けるところから始めれば大丈夫です。

この記事が、AIを活用した業務改善の第一歩を踏み出すきっかけになれば嬉しいです。

こんにちは、2026年3月入社の大園です！

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

大園博昭


• 自己紹介
  • Engineering Officeの大園です！
  • Xはこちら
  • 会社横断での経営・組織課題を解決するという幅広いミッションを受け持つチームの中で、主にソフトウェアテスト周りや生成AI周りの技術部分を担当しています
• 所属チームの体制は？
  • 上長が名古屋、他チームメンバー3人が東京、私が福岡所属と全国に散らばっています
  • やっていることは全員バラバラの個人商店なチームですが、毎日ZoomやSlackでワイワイやっております
• KTCへ入社したときの第一印象？ギャップはあった？
  • 入社前からいろんな話を聞かせていただいていたのと、自分がどんなことで貢献できそうかというイメージをしっかり持っていたため、特に大きなギャップはなかったです。
• 現場の雰囲気はどんな感じ？
  • 福岡オフィスは去年できたばかりというのもあり、人数もまだ10人未満。自分たちで一から作っている感が楽しいです！
• ブログを書くことになってどう思った？
  • 今後どんどん書いていきたいと思います！
  • ブログではないですが、6/4に福岡オフィスにおいてE2Eテスト x AIというテーマで勉強会を開催しました。今後もKINTOテクノロジーズの魅力発信や福岡エンジニアを盛り上げる活動を積極的にしていきたいと思います！
• 高さん ⇒ 大園さんへの質問

  福岡の豚骨らーめんの中で、一番美味しい店について教えてください

  • これは戦争が起きかねない非常にセンシティブな質問ですね…私は昔ながらのとんこつラーメンが好きなので元祖長浜屋です！

森重香一


• 自己紹介
  • 業務システム開発部業務システムGの森重です。
  • KINTO事業のシステムのうち、債権領域のビジネスアナリスト（BA）を担当しています。
  • BAは開発チームと業務部門の橋渡し役で、要件整理や関係者調整が主な仕事です。
  • 大阪オフィス勤務で、前職は業務システム開発に携わっていました。
• 所属チームの体制は？
  • 直属チームは4名（東京3名・大阪1名）で、同期入社の田平さんも同じチームです。
  • 田平さんの紹介と合わせて読んでいただけると体制がより伝わるかと思います。
  • 離れていても Slack やオンラインミーティングで日々連携できています。
• KTCへ入社したときの第一印象？ギャップはあった？
  • 「テックベンチャー」という言葉から、技術中心で少し距離感のある組織をイメージしていました。
  • 実際に入社してみると、勉強会や交流イベントが多く、所属チーム外の方とも自然に話せる機会がたくさんありました。
  • 良い意味でイメージとのギャップを感じています。
• 現場の雰囲気はどんな感じ？
  • 落ち着いた雰囲気の中で、それぞれが主体的に動いている印象です。
  • 困ったときは気軽に相談できますし、Confluence や Slack を活用した情報共有が活発で部門を超えて動きやすいです。
  • 個人で進める部分とチームで議論する部分のバランスが良いと感じています。
• ブログを書くことになってどう思った？
  • これまで読む側だったので、書くのは少し緊張しました。
  • ただ振り返ってみると、入社後の気づきを言語化する良い機会になりました。
  • 入社を検討されている方に少しでも雰囲気が伝わればうれしいです！
• 大園さん ⇒ 森重さんへの質問

  最近行った旅行でオススメの観光地などあれば教えてください！

  • 昨年末に友人と犬山城へ行きました。
  • 今年の大河ドラマ「豊臣兄弟！」が始まることもあり、放送前に戦国ゆかりの地を訪れてみようと思ったのがきっかけです。
  • 実際に訪れてみると、テレビや写真で見るよりも天守はコンパクトな印象でしたが、その分、現存天守ならではの歴史をぐっと身近に感じることができました。
  • 黒い外観も印象的で、少し離れて見ると存在感がありました。
  • 城下町は大規模な観光地というより歩きながらゆっくり楽しめる雰囲気で、食べ歩きや散策をしながら半日ほど過ごせます。名古屋からのアクセスもよく、週末の小旅行としておすすめです。

佐藤誠


• 自己紹介
  • プラットフォーム開発部xREグループDBREチーム 所属の佐藤誠です。
  • KTCのDBRE業務全般を担当してます。AWS Aurora MySQLをたくさん使っていますが、PostgreSQLも社内で安全に使えるように整備を進めています。
• 所属チームの体制は？
  • DBREチームは5名体制で、全員神保町所属です。
• KTCへ入社したときの第一印象？ギャップはあった？
  • 入社前にオフィス見学などもさせてもらっており、印象通りでした。
• 現場の雰囲気はどんな感じ？
  • 神保町オフィスはいわゆる古書街から少し南に下ったところにあり、オフィス周りを歩くだけで発見がたくさんありますね。ラーメン、カレー、中華、洋食も名店がたくさんあり、ランチは毎日の楽しみです。オフィス内はまだ知り合いが少ないのでこれからですが、皆さんシゴデキな雰囲気があります。
• ブログを書くことになってどう思った？
  • いつ来るかと思ってたら入社して3か月経ってました。
• 森重さん ⇒ 佐藤さんへの質問

  散歩が趣味とのことですが、歩いていて起きた忘れられない出来事やハプニングがあれば教えてください！

  • 道を聞かれたり、駅近だと寸借詐欺っぽいことはよくあるくらいですかね。。。散歩の醍醐味としては駅間の移動が点の移動に対して、徒歩は線・面の移動になるので、いろいろな気づきがありますね。雰囲気の良い公園とか地元の小さな雑貨屋が見つかったり。河川敷とか線路沿いをよく歩きますが、人の営みを感じられて良いです。

田平亨斗


• 自己紹介
  • 業務システム開発部業務システムGの田平です。
  • KINTO事業のシステムのうち、与信領域の開発・運用を担当します。
  • 東京の室町オフィス勤務ですが、最近は神保町にいることも多いです。
• 所属チームの体制は？
  • 直属のチームは4名体制で、東京3名大阪1名です。
  • 加えて、他の部や協力会社の方に入っていただいている形です。
• KTCへ入社したときの第一印象？ギャップはあった？
  • 入る前はもっとトヨタ色が強いと思っていました。実際は逆で、そういった物に縛られない集団を目指していると認識しています。
  • 案外車に乗ってない方も多い印象。サーキットを走られているような方もいて多様性があると思います。
• 現場の雰囲気はどんな感じ？
  • 中途採用で経験豊富な方ばかりで、落ち着いた印象です。
  • オフィスごとに結構雰囲気も違いそうで、色々行ってみたくはあります。
• ブログを書くことになってどう思った？
  • 選考時から存在は知っていたのですが、入社後無事こうしてブログを書けているのがまずは良かったという感じです。
• 佐藤さん ⇒ 田平さんへの質問

  明治大正の建物のおすすめがあれば教えてください（迎賓館赤坂離宮は自分も大好きです）

  • なんといっても上野・湯島の旧岩崎邸庭園がオススメです。都会の喧騒を離れた落ち着いた環境で、装飾やタイル、金唐革紙など見どころが多い所です。
  • 昭和初期にはなりますが、白金台の庭園美術館（旧朝香宮邸）も赤坂離宮と同様に豪奢な印象、アールデコの装飾が非常に多く見応えがあるかと思います。
  • ついでに大阪あたりだと芦屋のヨドコウ迎賓館が非常にオススメ。福岡はめちゃくちゃ現代ですが、天神地下街が素晴らしい。名古屋には何と言っても明治村があります！

高斯


• 自己紹介
  • デジタル戦略部 データサイエンスGの高（si gao）です。
  • データ分析を担当しています。
  • 東京オフィス勤務です。
  • 趣味：サッカー観戦 / プレー / 漫画アニメ鑑賞 / ゲーム
• 所属チームの体制は？
  • デジタル戦略部のデータサイエンスGに所属し、データ分析を担当しています。
  • チームは3名体制です。
  • 分析に使っている言語・ツール例：Python / SQL / BIツール など。
• KTCへ入社したときの第一印象？ギャップはあった？
  • 入社前はもっとお堅い雰囲気を想像していました。実際はフラットで風通しがよく、データやテクノロジーで事業を前に進めようという空気の強い組織だと感じました。
  • エンジニアやデータ分野のスペシャリストが多く、それぞれの専門性を持ち寄って課題に取り組んでいる点が良い意味でのギャップでした。
• 現場の雰囲気はどんな感じ？
  • 落ち着いていて相談しやすい雰囲気で、分からないことを聞きやすい環境です。
  • 東京オフィスは設備も整っていて働きやすく、チームを越えた交流の機会もあります。
• ブログを書くことになってどう思った？
  • 入社して間もないタイミングで、自分の言葉で会社や仕事を振り返る良い機会になりました。
  • リレー形式で前の方からの質問に答えるのが新鮮で、楽しく書けました。
• 田平さん ⇒ 高さんへの質問

  サッカーかなりお好きなのではないかと思いますが、どういった所に魅力を感じていますか？

  • 大きく3つあります。
  • どんな体型・体格の人でも活躍できるところ。背が高くなくても、足が特別速くなくても、技術や判断力、ポジショニングで輝ける選手がたくさんいます。多様な個性が同じピッチで成立するのがサッカーの面白さだと思います。
  • 想像力が問われるところ。次のプレーを読み、スペースを作り、味方の動きを予測する——決まった正解のない中で発揮される創造性に毎回ワクワクします。
  • チームワーク。一人のスター選手だけでは勝てず、全員が役割を全うして初めて勝利に近づく。個と組織のバランスが取れた瞬間の美しさが一番の魅力です。

さいごに

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

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

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