この記事でわかること 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」 が開催されました。私は会場提供・運営サポートを担当しつつ、参加者としてハンズオンにも取り組みました。 本記事は、その開催報告です。  当日のエントランスの様子 開催したイベントの概要 項目 内容 イベント名 Osaka | Claude Managed Agents Workshop （Claude Community Event） 開催日 2026年7月31日（金）18:30〜21:05 会場 KINTOテクノロジーズ Osaka Tech Lab JCT（大阪市北区梅田3-1-3 ノースゲートビルディング20階） 主催 森田さん（Claude Community Ambassador） 会場提供 KINTOテクノロジーズ 参加者 約30名 タイムテーブルは次のとおりです。 時間 内容 18:30〜19:00 受付・交流 19:00〜19:10 オープニング・会場説明 19:10〜19:30 Claude Managed Agentsの解説 19:30〜20:45 ハンズオン（個人ペース） 20:45〜21:00 ネットワーキング 21:00〜21:05 クロージング 会場提供の経緯 主催の 森田さん は 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つです。 概念 何を指すか エージェント 使うモデル、システムプロンプト、ツール、MCPサーバー、スキルをまとめた設定。一度作ればIDでセッションから参照できる 環境 エージェントを走らせる場所。Anthropic側のクラウドサンドボックスと、自分たちで管理するインフラ上で動かすセルフホスト型が選べる セッション 環境の中で実際に動いているエージェントの実体。タスクを実行して成果物を残す イベント アプリケーションとエージェントのあいだで交換されるメッセージ。ユーザーの指示、ツールの実行結果、ステータス更新などが該当し、レスポンスはSSEでストリーミングされる ハンズオンも「エージェントを作る → 環境を作る → セッションを起動する → メッセージを送る」という順番をそのままたどる構成になっていたので、この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月にも開催されます 。 項目 内容 イベント名 Osaka | Claude Workshop 開催日 2026年8月18日（火） 会場 クラスメソッド株式会社 大阪オフィス（大阪市中央区伏見町3-6-3 三菱UFJ信託銀行大阪ビル8階） 主催 森田さん（Claude Community Events） 解説のあとハンズオンという流れは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月に入社し、AI for applicationチームにジョインしました村上です。 キャディ株式会社では、プロダクトが解くべき課題を正しく捉えるには現場業務への解像度が不可欠だという考えから、ドメイン知識をキャッチアップするための仕組みが社内に用意されています。その一つが「調達もくもくワーク」という体験型トレーニングです。 私自身、前職では製造業とは全く関係のない業界でMLエンジニアをしていました。そのため製造業のバックグラウンドはゼロです。 今回、ドメイン知識を身につける機会として上長にお勧めされ、「調達もくもくワーク」に参加しました。 この記事では、製造業未経験のMLエンジニアである筆者がこのワークに参加し、調達業務のペインを体験したうえで感じたことを書きます。 用語の整理 調達業務の概要 調達もくもくワークとは ワークでの体験 1.見積先の選定 手作業 CADDi Quote 2.見積依頼 手作業 CADDi Quote 3.見積結果の査定 手作業 CADDi Quote 体験してどう変わったか AIやシステムが引き受けるべき仕事 製造業全体の最適化の難しさ We are hiring 用語の整理 この記事で使う主要な製造業用語をまとめます。その他の用語は本文中で適宜補足します。 調達 : 自社製品に必要な部品や材料を外部から購入・手配する業務全般を指します。購買とほぼ同義ですが、サプライヤーの選定や価格交渉まで含む広い意味で使われます。 サプライヤー : 部品を製造・納品する外部の加工会社のことです。「協力会社」「外注先」とも呼ばれます。 バイヤー : 調達担当者のことです。サプライヤーに見積を依頼し、発注先を決定する側を指します。 図面 : 製造する部品の設計書です。形状・寸法・材質・表面処理などを記載した技術文書で、調達業務ではPDFや紙でやり取りされます。 見積 : サプライヤーが図面をもとに提示する価格・納期の回答です。複数社から見積を取ることを「相見積」と呼びます。 QCD : Quality（品質）・Cost（コスト）・Delivery（納期）の頭文字です。調達判断の際に考慮すべきパラメータです。 CADDi Quote : キャディが提供する製造業AI見積クラウドです。図面のアップロードから見積依頼・回答比較までをカバーします。 CADDi Drawer : キャディが提供する製造業データ活用クラウドです。図面からの情報の構造化や図面の形状認識が強みの一つになっており、類似した図面の検索が可能になっています。 調達業務の概要 調達担当者の仕事は、設計部門から受け取った図面をもとに外部のサプライヤーに部品の製造を依頼し、QCDを守って納品してもらうことです。大まかな流れは以下のとおりです。 図面受領・確認 : 設計部門から部品表と図面を受け取る。 カテゴリ分け : 図面を見て、切削・板金・購入品などに仕分ける（サプライヤーは加工種別ごとに専門が分かれているため、ここでの振り分けが必要）。 見積先選定 : サプライヤーリストから対応可能なサプライヤーを選ぶ。過去の発注実績と突合し、新規品かリピート品かを判定して加味する必要がある。 見積依頼の送付 : 見積依頼書を作成し、図面を添付してメールで送付する。 見積回答の査定 : サプライヤーからの回答を比較し、QCD観点で発注先を決める。 発注 : 発注書を作成してサプライヤーに送る 調達もくもくワークとは 調達もくもくワークは、CADDi Quoteのユーザーである調達担当者の業務を、サンプルの図面や発注実績などを使って実際に手を動かしながら追体験するトレーニングです。調達業務の一部についてまずCADDi Quoteなし（手作業）で苦しんでから、CADDi Quoteありでやり直します。ビフォー・アフターを自分の手で体験する設計です。ワークでは上記フローのうち、見積先選定・見積依頼の送付・見積回答の査定を体験しました。調達業務にどのようなペインがあり、それをCADDi Quoteがどう解決しているのかを肌で知ることが目的です。実際にはCADDi Quoteなしで一通り体験した後にCADDi Quoteを体験したのですが、読みやすさのため各フェーズの中で両方の感想を書きます。 調達もくもくワークの様子。 硬い雰囲気に見えますが、実際には気軽に質問したり手作業の煩雑さに愚痴を言いながら進めていました。 ワークでの体験 1.見積先の選定 ワークでは「どのような部品をどれだけいつまでに調達する必要がある」というような依頼が調達部門にきている状態からスタートします。それぞれの部品をどこのサプライヤーから調達するかを考える必要があります。どのサプライヤーがどんな加工に対応でき、過去にどんな品質・納期実績があったかというような情報が体系的にまとまっていることは稀です。結果として現場ではベテランの経験則に依存していることもよくあるようです。また、過去にいくらの金額で発注したかという情報はあったとしても、発注には至らなかった見積結果についてまとまっていることはほとんどないようでした。 研修で使用したダミーの取引実績とサプライヤー情報。このような情報がまとまっていること自体ほとんどないそうです。 手作業 手作業ワークでは過去の発注履歴スプレッドシートが用意されていたのでそれを頼りに選定しました。しかし注文実績があっても過去の品質や価格の妥当性はわかりませんでした。経験則がないこともあり自分は見積をもらってから考えれば良いかとなり、多めのサプライヤーに見積を出すことにしました。 今回はスプレッドシートに過去の情報がまとまっていたのでまだマシでしたが、実際にはどこにもまとまっていないことも多いとのことで、効率的な調達先の選定はかなり難しそうだと感じました。適切でないサプライヤーへの見積依頼はサプライヤー側への負担になりますし、見積に対する発注比率も下がることで、信頼関係を損ねることにもなります。 CADDi Quote CADDi Quoteを使ったワークでは過去実績の比較が非常にやりやすくなっていました。過去の発注履歴や図面の情報をCADDiに貯めてもらっていることが前提とはなっていますが、図面IDと必要な加工情報を渡せば過去の発注実績を元にサプライヤーの候補が得られます。発注価格・見積履歴・過去のトラブルなど、見積依頼先を決めるために必要な情報がまとまっていました。 少しだけ過去と異なるような部品を発注する場合、図面IDだけを見ていると新規品であるため発注先の選定を機械的にしづらいという問題があります。しかしCADDi Quoteは今回発注する図面だけではなく、その図面に類似した図面に対する発注実績も加味してくれます。この機能は図面の形状解析が高精度でできるCADDiならではの強みです。 2.見積依頼 見積先を決めた後、各サプライヤーにメールで見積依頼を送ります。図面をPDFとしてメールに添付して送ることも多いようです。サプライヤーごとに見積依頼書の中身や宛先名を変更する必要がありますし、依頼する図面が違うので正しい図面をメールに添付する必要があります。作業自体は単純で機械的に進めていけば良いのですが、ミスを誘発する要素が多いです。 手作業 ワークでは見積先として選定した宛先（実際には研修を担当していただいた先輩のメールアドレス）に見積依頼を送る作業を行いました。各サプライヤーごとに見積依頼書の作成を行い、図面を添付してメールを送るだけの作業です。単純に見える作業ですが実際には時間とストレスがかなりかかります。他社宛の依頼書を送ったり、図面を添付し忘れたりする人が当然続出しました。自分は見積先を多く選定してしまっていたのもあり、結局途中から作業が嫌になり見積依頼先をこっそり減らしてしまいました。ワークでは実務と比べると少量の部品やサプライヤーでの体験だったのですが、本当に真面目にミスなくやろうと思うと1時間以上は平気でかかりそうでした。機械的な作業に感じられ個人的には一番の苦痛でした。 見積書と大量の図面添付の例。一つ一つ図番を確認しながら添付していくのはかなり注意力を消費します。 CADDi Quote CADDi Quoteを使ったワークでは劇的に楽になっていました。上流工程である見積先選定の結果から数クリックするだけで見積依頼書の作成からメールの送信まで自動で行ってくれました。1時間はかかるであろう作業が数秒になるのには流石に感動しました。 3.見積結果の査定 見積依頼を出した後、それぞれのサプライヤーから見積結果が返ってくるのを待ちます。見積結果が出揃ってきたらその結果を取りまとめてどこに発注を出すかを決めることになります。その際にはQCD（品質、コスト、納期）全体を加味して発注先を決める必要があります。 見積にかかる時間はサプライヤーによって当然異なるので見落としがないように気を付ける必要があります。また、一つのプロジェクトの部品の調達だけをしていれば良いわけではないため、見積結果を待っている間には他の部品の調達も並行して進めなければなりません。待ち時間がある分、情報の整理や管理が必要とされるフェーズです。 手作業 ワークでは時間が決まっているので見積結果は用意されている状態でこのフェーズが始まりました。見積結果を見ていると各社フォーマットが異なっており、比較可能な状態に整理すること自体にまず時間がかかりました。 見積結果の例。カラム名が異なり機械的に統合できなかったり、条件付きでの見積結果だったりと単純に比較することが難しいです。 見積金額には条件がついていることもあり、特定の加工をする部分は除いての金額であったり、見積依頼をした部品全てをまとめて一括発注することを条件としたケースでの金額が記載されていることもあり、比較が大変でした。見積結果をスプレッドシートにまとめた後も、その判断は難しいです。結局私はシンプルに加工費を見て一番安い組み合わせを探してそこに発注するという判断をしました。実際には定性的な要素も多く絡み、トラブル対応が柔軟なサプライヤーであるかどうかや、工場の位置が近く輸送に関わる問題があるかどうかなど、複合的に考える必要があるとのことでした。 CADDi Quote CADDi Quoteから送られた見積依頼のメールには専用のフォームが用意されており、サプライヤーはそこから見積結果を返答します。その結果はCADDi Quoteに自動で連携されます。どこに見積依頼を送ったのか、どこから結果が返ってきてどこがまだなのか、見積結果はいくらなのか。こうした情報が一元的に管理されていきます。 金額による比較は当然できますし、サプライヤーごとの注意事項などもまとめておき表示できるため、定性的な評価もある程度できるようです。現状ではサプライヤー側からの条件付きの見積結果については対応できる幅に限度がありそうなため、CADDi Quoteだけで業務を完全に代替できるわけではありません。しかし、人手でやっていた面倒な作業部分をサポートして楽にするという形での貢献になっていそうでした。 体験してどう変わったか AIやシステムが引き受けるべき仕事 今回のワークでは、調達業務における「機械的作業」と「判断業務」の混在が鮮明になりました。頻繁な情報の紐付けや転記、照合といった定型作業は、画面やファイルを行き来しながらミスなく行う必要があり、想像以上に大きな負荷となります。本来、システムが担うべきなのはこうした作業です。調達担当者が真に時間を割くべきなのは、新規サプライヤーの開拓やコスト削減、サプライチェーン全体のリスク戦略といった、人の判断力や創造性が求められる本質的な仕事です。しかし、定型作業に忙殺されている限り、そこに時間は割けません。 MLエンジニアとしての視点では、複雑なアルゴリズムによる解決策に目が行きがちですが、現場ではデータの紐付け自体が手作業で行われており、それが最大のボトルネックになっています。ロジックの精度以前に、データを構造化して蓄積し、活用できる状態を作ることが最優先でした。CADDi Quoteは、こうした泥臭い紐付け作業をシステム化することで、人が本来の業務に集中できる環境を提供しています。 さらに、CADDi Quoteには蓄積されたデータを分析し、調達をより効率化するインサイトを導き出す機能も備わっています。売上の50%以上を占めることもある調達・購買において、これまでベテランの勘に頼っていた決定を、整理されたデータに基づいて行えるようになります。データの蓄積と分析によって、単なる作業効率化を超えた、より戦略的で価値のある調達の実現を目指しています。 製造業全体の最適化の難しさ 調達金額の最適化について考えを深めていくと、次第に「サプライヤー（加工会社）側の大変さ」も気になり始めました。サプライヤーは、基本的に見積依頼に無料で対応します。安すぎる金額を提示すれば受注できても赤字になり、逆に高すぎれば発注をもらえず、見積に費やした工数がタダ働きになってしまいます。図面だけでは条件が曖昧な場合、発注側とのすり合わせにかかるコミュニケーションコストも無視できません。調達業務の負担はバイヤー側だけのものではなく、製造業全体の効率化を考えるには、多数のステークホルダーの目線に立つ必要があると痛感しました。 また、「片側だけの効率化が、必ずしも全体最適につながらない可能性」も感じています。CADDi Quoteによって調達側の作業が楽になり、扱える案件数が増えれば、バイヤーがサプライヤーに送る見積依頼の総数も増えるかもしれません。もちろんシステムの精度が上がれば的外れな依頼は減るはずですが、バイヤー側の処理能力が爆発的に向上することで、結果的にサプライヤー側の対応負荷が変わらないどころか、むしろ増えてしまうというパラドックスも起き得ます。 これは確信のある主張というよりも、ワークで感じた問いです。調達プラットフォームを考えるとき、バイヤー側の効率化だけでなく、サプライヤー側にも見積対応の効率化や受注機会の可視化といった価値をセットで提供していく視点が必要なのだろうと感じました。製造業全体のエコシステムを良くするのは、一方向の最適化では済まない難しい問題です。 「モノづくり産業のポテンシャルを解放する」という大きなミッションを達成するには、このようなステークホルダーが多く複雑な問題も避けては通れません。実際CADDi Quoteもこの大きな問題を解決するための変革が現在進行形で進んでいます。1日の体験ワークでこうした問いが自然に浮かんできたこと自体が、このワークショップの設計のうまさだと感じました。 We are hiring ミクロに実際の現場の問題に向き合いながらも、長期的にはマクロに製造業全体の効率改善を目指していける環境です。 製造業が未経験であっても、このようなワークを通じてドメイン理解を深めることができます。 このような立ち位置で働けることにワクワクを感じる方がいれば、製造業未経験でもぜひお話をしましょう！ tech.caddi.com

こんにちは、サイバーセキュリティと生成AI活用推進を担当しているたなちゅーです。この記事では、2026年2月に活動を開始したAI-Native Devプロジェクトについて紹介します。 活動の背景 2025年までの取り組み KTCでは2024年の 生成AI活用プロジェクト を皮切りに、2025年は「AIファースト」「リリースファースト」を掲げ、AI活用は着実に進みました。 AIファースト ：すべてのプロダクトへのAI統合、AIプロダクトの開発推進、グループ内でのAI活用ドライバー リリースファースト ：「いかに速く届けるか」を文化として組織に定着させる 「AIを使う」から「AIネイティブな開発・業務プロセス」へ こうした取り組みを経て、昨年末に副社長の景山がテックブログ「 2025年の振り返りと2026年の展望：Agenticな未来へ 」で、2026年のキーワードとして「Agentファースト」と「AIエンジニアリングファースト（AI-Native Dev）」を掲げました。 Agentファースト ：「対話するAI」から「行動するAI」へ。AIが自律的にタスクを遂行する世界を全社で実現する AIエンジニアリングファースト（AI-Native Dev） ：AIネイティブな視点で開発・業務プロセスを再構築し、職種の壁を超える 目指すのは、 一人ひとりがAIネイティブな視点で開発や業務のプロセスを変えていくこと 。その推進役として、2026年2月にAI-Native Devプロジェクトが発足。プロダクト開発からクラウドインフラ、コーポレート部門まで、10名超が合流した横断チームで活動を開始しています。 活動の2つの柱 個人の知見を組織全体で活かす仕組みと、それを支える開発環境の整備。この2つが揃って初めて組織として加速できると考え、活動を 文化醸成 と 開発環境整備 の2本立てで構成しています。 文化醸成 ：ナレッジの体系化・共有、AIツール利用状況の可視化、社内事例の発信など 開発環境整備 ：AI時代のコードレビュー最適化、AI Agent / MCP基盤の整備、エンバイロメント（環境）エンジニアリングなど Phase 1：まず土台をつくる Phase 1として取り組んだのは、活動の土台となる2つの基盤です。 AI Native Hub 1つ目は、社内Wiki上に開設した生成AI活用の社内ポータル「AI Native Hub」です。 職種別のAIツール活用ガイド、MCP・Skillsの使い方、社内事例などの情報を集約しています。また、コンテンツの運用にはGitHubを採用しています。Markdownで記述し、PRでレビューを回し、mainブランチにマージされると社内Wikiへ自動同期される仕組みです。運営チームだけが管理するのではなく誰でもナレッジを共有できる、社内全体で育てていくナレッジ集約場所を目指しています。 Claude Code Dashboard 2つ目は、Claude Codeの利用状況を可視化するダッシュボードです。Claude CodeのOpenTelemetryを活用しています。 ダッシュボードでは、MCPやSkillsの使用回数、利用者のトークン使用量、トークン使用量上位者のトレンドが見えます。自分の活用状況の振り返りやトークン使用量上位者との交流など、AIツール利用促進のきっかけになればと考えています。 Phase 2：実践と拡張 Phase 1は立ち上げと基盤整備。4月からのPhase 2は、その基盤の上で実践を加速するフェーズです。 文化醸成 文化醸成が目指すのは、AIネイティブな開発・業務のスタイルが組織に根づくことです。 もくもく会・ハンズオン会 ：気軽に情報交換できるオンラインの場を定期開催し、実践知を共有する AIネイティブな個人・部署へのインタビューとナレッジの横展開 ：先行事例を掘り起こし、他チームへ広げる AIネイティブな活動の可視化 ：AIネイティブ度合いを可視化し、活動の推進に活かす まず動き出したのが「もくもく会」です。週2回オンラインで開催して、ちょっとした困りごとやTipsなどを話しています。また、テーマを決めたハンズオン会も実施しており、初回の「Claude Codeを使い倒す設定を一緒にしよう会」には合計80名以上が参加しました。学びは集約して、後から参照できる形にしています。 開発環境整備 開発環境整備が目指すのは、AIエージェントを前提とした開発基盤を整えることです。 AI Agent / MCP基盤の整備 ：AI AgentやMCPの共有基盤の整備を進め、誰でも見つけて使える状態を目指します。 AI時代に合わせたコードレビューの最適化 ：AIが生成したコードに対するレビュー観点や静的解析との連携など、AI前提のレビューフローを検討しています。 エンバイロメント（環境）エンジニアリング ：AIエージェントが安全に活動できる範囲の境界線設計やガードレールなどの整備に取り組んでいきます。 既に社内ではエージェント開発・共有基盤「KTC Agent Store」を運用しており、現在は実行基盤をBedrock AgentCoreへの移行を進めています。AIエージェントとしてはAIインタビューという深堀りインタビューエージェントなどの開発が進行中です。 ここまでの活動で感じたこと 一番の発見は、AIネイティブな働き方に既に踏み出しているメンバーの多さです。初回ハンズオン会には80名以上が参加し、チャットではおすすめ設定や活用Tipsが飛び交いました。この熱量をつなげれば、もっと大きな力になる。その点と点をつなぐことがAI-Native Devの役割だと改めて感じています。 また、AIネイティブな開発・業務スタイルが根づけば、日々の業務から生まれた余力が新たな価値創出へ向かう流れをつくれるはずです。「攻めのAI活用」と「守りの安全基盤」の両面をつなぎながら、その流れを組織全体で加速させていきます。 おわりに AI-Native Devは始まったばかりです。土台を作るフェーズから、土台の上で走るフェーズへ。活動の進捗やナレッジは引き続きテックブログで発信していきます。 最後まで読んでいただきありがとうございました！