はじめに こんにちは、IoT Specialist ソリューションアーキテクトの新澤です。2026 年 6 月 25〜26 日に幕張メッセで開催された AWS Summit Japan 2026 の「生産ラインの未来」ブースでは、AI エージェントが生産ラインのボトルネックを検知し改善策を提案するデモを展示しました。 開催前の予告ブログ ではデモの概要をご紹介しましたが、本記事では展示を終えた今、その実装の詳細を解説します。 このデモのテーマは、「AI エージェントに工場の「構造」をどう教えるか」です。どの製品にどの部品が必要で、どの設備で加工し、どのサプライヤーから調達しているか。こうした関係性が構造化されていなければ、AI は参照すべきデータソースを判断できず、回答が不安定になったり、必要なデータに到達するまでの試行錯誤が増えたりします。本デモではこの関係性をスキーマとして定義し、ナレッジグラフとして実装しました。一方、スキーマだけでは「今」が分かりません。設備のサイクルタイムは今何秒か、現状の設備で増産対応が可能なのか。ここに IoT のリアルタイムデータを接続することで、AI エージェントは構造を知った上で現状を踏まえた判断を行えるようになります。まず、なぜ製造業にナレッジグラフが必要なのかという課題から出発し、グラフスキーマの設計、データストアの役割分担、AI エージェントの推論フロー、全体アーキテクチャの順に解説します。 なお本記事では、製品・部品・設備・サプライヤーといった要素間の関係性をグラフ構造で表現したものを「ナレッジグラフ」と呼ぶこととします。これは OWL や記述論理に基づくいわゆるオントロジー (TBox/ABox による概念公理や自動推論)とは異なり、AI エージェントが「どのデータをどう辿るか」を判断するためのセマンティックなコンテキスト情報として活用することを目的としています。また、本記事で「推論」と呼ぶのは、記述論理（OWL など）による論理推論ではなく、AI エージェント（LLM）がナレッジグラフを文脈として複数のデータソースを横断し、回答を組み立てる処理を指します。 デモ画面:生産ラインのナレッジグラフマップ なぜ製造業にナレッジグラフが必要か 突然の増産指示「来月末までに 300 台追加で出荷できるか?」この問いに答えるには、オーダー → 製品 → 部品 → 在庫 → サプライヤー → 設備稼働と、異なるシステムに散在するデータを横断的に辿らなければなりません。難しいのは個々のデータを取ることではなく、それらのデータ間の依存関係を何段も辿り切らなければならない点にあります。さらに各データは多対多の関係を持ちます。1 つの製品は複数の部品を必要とし、1 つの部品は複数のサプライヤーから調達可能で、1 台の設備は複数の製品の工程に関与します。増産対応に限らず、このような「多段の関係性探索」は製造現場で繰り返し発生します。 特に顕著なのが BOM (部品表) の探索です。BOM はツリー構造で、増産の実現性判断では BOM を順方向に展開して必要部品を洗い出す必要があります。一方、品質問題のトレーサビリティでは逆方向に辿って「この素材を使っている全製品は」を特定します。設計変更の影響確認でも同様です。しかも構成が何階層あるかは製品ごとに異なるため、探索の深さを事前に固定できません。本デモでは以下の 3 階層の BOM を定義しました (来場者の方から「うちは 100 階層を超える」という声もいただきました) 。 SD1 圧力センサーモジュール (完成品) ├── センサーユニット (サブアセンブリ) │ ├── セラミック圧力センサー素子 │ └── 配線ハーネス ├── 駆動ユニット (サブアセンブリ) │ ├── ブラシレスモーター ×4 │ └── モータードライバ IC └── フライトコントローラー 「300 台増産できるか」の判断には、部品ツリーを最下層まで展開し、在庫・リードタイム・設備の稼働状況を確認する必要があります。RDB では構成表テーブルを何段階も繰り返し結合して検索するため、部品が増えるほど処理が重くなります。一方、ナレッジグラフなら階層の深さに関わらず 1 行のクエリで記述でき、順方向・逆方向の検索もまったく同じ構文で対応できます。 // 順方向: 増産に必要な全部品を展開 g.V('PROD-SD1').repeat(out('REQUIRES')).emit().valueMap('name') // 逆方向: 不良素材の影響を受ける全製品を特定 g.V('PART-CERAMIC-001').repeat(in('REQUIRES')).emit().valueMap('name') ナレッジグラフの利点は、探索の書きやすさだけではありません。ユーザーにとって直接的なメリットが 2 つあります。 1 つはコストです。グラフ探索は問いに関係するサブグラフだけを返すため、テーブルや文書を丸ごと LLM のコンテキストに渡す必要がなく、消費トークンを抑えられます。またグラフが「次にどこを見るべきか」を示すため、エージェントが無関係なデータソースを探索して往復する無駄も生じません。もう 1 つは回答の信頼性です。エージェントは LLM の記憶ではなく、グラフに格納された検証済みの関係を根拠に回答を組み立てます。ナレッジグラフによる知識の裏付けがハルシネーションの抑制に有効と考えられます。 ここからは、これらの利点を実際のデモでどう形にしたかを解説します。 グラフスキーマの設計 まずは、AI エージェントに接続したデータソースと、その関係性を定義したグラフスキーマの設計から解説します。 デモで用意したデータソース AI エージェントが増産の実現性を判断するために、以下のデータソースを用意しました。 生産オーダー (Amazon DynamoDB) : どの製品をいつまでに何個作るかを管理します。本デモでは「SD1 圧力センサーモジュール 300 台、納期 7/10」のオーダーを投入しています。 BOM — 部品表 (Amazon Neptune ナレッジグラフ) : 製品に必要な部品の構成を定義します。前セクションで示した 3 階層のツリー(完成品 → サブアセンブリ → 部品)が REQUIRES エッジとして格納されています。 在庫 (Amazon DynamoDB) : 各部品の現在の在庫数量と安全在庫を保持します。例 : セラミック素子 10,000 個、ブラシレスモーター 30,000 個。 サプライヤー (Amazon Neptune ナレッジグラフ + Amazon DynamoDB) : 部品と調達先の対応関係は SUPPLIED_BY エッジとしてグラフに、リードタイムや最小発注数量などの値は Amazon DynamoDB に持たせています。例: セラミック素子は LT 14 日、ブラシレスモーターは LT 21 日。 設備稼働データ (AWS IoT SiteWise) : 各ステーション(受入検査、搬送、自動倉庫、加工、組立、出荷)のリアルタイムなサイクルタイムと稼働率を 1 分間隔で収集しています。Amazon Neptune の Equipment ノード ID と AWS IoT SiteWise のアセット ID を共通化しているため、グラフ探索で特定した設備の最新値を、ID 変換なしにそのまま取得できます。 工程設計書・FMEA (Amazon Bedrock Knowledge Bases) : 各工程の加工条件や運転手順を記述した工程設計書(Word ファイル)、FMEA(Excel ファイル)、PLC コーディング規約(Word ファイル)などのドキュメントを RAG 検索可能にしています。 グラフスキーマの全体像 本デモでは「増産オーダーの実現性診断」を頻出ユースケースとして特定し、そのグラフ探索パス (オーダー → 製品 → 部品 → 設備) を専用ツールとして事前実装しました。ユースケースに登場するエンティティをノード、関係をエッジとして Amazon Neptune に格納し、鮮度の高いデータ (サイクルタイム、在庫数量等) は IoT サービス群や Amazon DynamoDB に分離しています。静的な構造と動的な値を分けることで、レスポンス速度と回答精度を安定させることを目指しました。 しかし、現場では設備起点の問いも発生します。デモでは「オーダー起点で、影響する設備を探しに行く」パスを実装しましたが、現場ではその逆方向、設備で異常が起きたときに「何に影響するか」を知りたい場面が日常的に発生します。「焼成炉の温度が基準を超えた。この設備が停止したら、どの製品の出荷が遅れるか?」、「切削精度の劣化が検出された。同じユニットを使う他ラインの品質にも影響するか?」。これらはグラフ上の同じデータ構造を起点を変えて辿るだけなので簡単な話ですが、事前に定義した固定的な探索パスだけではカバーできません。なので実運用では頻出パターンは専用ツール (固定探索) で高速かつ安定した回答を返し、それ以外の問いには汎用グラフ探索 (LLM がノードの隣接関係を見て自律的に辿る方式) をフォールバックとして組み合わせるハイブリッド構成が現実的ではないかと考えています。 以下は、今回作成したグラフの全体像です。 本デモで定義したグラフスキーマ 本デモでは、グラフの実装基盤として Amazon Neptune を採用しました。Amazon Neptune 上に以下の 8 種類のノードと 10 種類のエッジを定義しました。以下は本ナレッジグラフのスキーマ (型定義) であり、実際の工場データ (インスタンス) はこの型に沿って格納されます。 ノードタイプ (8 種類) No. ノード 説明 例 1 Company 企業 AnyCompany 2 Factory 工場 Plant 02 横浜 3 Equipment 設備・ライン Production Line, Warehouse Station 4 SubUnit 設備内サブユニット Furnace Unit, Milling Machine 5 Product 製品 AnyCompany-SD1 6 Part 部品 セラミック圧力センサー素子 7 Supplier サプライヤー セラミック素材社 8 ProductionOrder 生産オーダー ORDER-2026-06-001 エッジタイプ (10 種類) No. エッジ 関係性 意味 1 CONTAINS Company → Factory 企業が工場を所有 2 HAS_EQUIPMENT Factory → Equipment 工場が設備を保有 3 HAS_SUBUNIT Equipment → SubUnit 設備がサブユニットを持つ 4 REQUIRES Product → Part 製品が部品を必要とする(BOM) 5 SUPPLIED_BY Part → Supplier 部品の調達先 6 STORED_AT Part → Equipment 部品の保管場所 7 PROCESSED_AT Part → Equipment 部品の加工場所 8 ASSEMBLED_AT Part → Equipment 部品の組立場所 9 PRODUCES ProductionOrder → Product オーダーの生産対象 10 EXECUTED_ON ProductionOrder → Equipment オーダーの実行設備 ISA-95 との対応 本デモのグラフモデルは、製造業の国際標準である ISA-95 の設備階層モデルと以下のように対応しています。 No. ISA-95 レベル 本デモのノード 説明 1 Level 4 — Enterprise Company ビジネス計画、オーダー管理 2 Level 4 — Site/Plant Factory 工場単位の生産管理 3 Level 2〜3 — Area/Work Cell Equipment 製造実行・各ステーション制御 4 Level 0〜1 — Control Module SubUnit 個別機器の制御 5 (サプライチェーン) Supplier, Part, Product, ProductionOrder ISA-95 外のビジネスエンティティ 本デモでは簡略化を目的として ISA-95 の Level 2〜3 を Equipment ノードに統合しています。実規模の適用時には、Work Center / Production Line / Work Unit を分離し、より詳細な階層を定義することも可能です。 ここまでで、グラフに格納する「構造」の設計を解説しました。一方、「グラフの全体像」で触れたとおり、鮮度の高いデータはグラフの外に置いています。次のセクションでは、この静的な構造と動的な値の分離を、データストアの役割分担として具体化します。 データストアの役割分担 本デモでは、データの特性に応じて 4 つのデータストアを使い分けています。 No. データストア 格納するもの 更新頻度 1 Amazon Neptune 静的な関係性 (BOM、設備構成、サプライヤー依存) 構造変更時のみ 2 AWS IoT サービス群 各設備のリアルタイム稼働データ (サイクルタイム、稼働率) 1 分間隔 3 Amazon DynamoDB 業務マスタデータ (生産オーダー、在庫、BOP) 日次〜週次 4 Amazon Bedrock Knowledge Bases 非構造化ドキュメント (工程設計書、FMEA、PLC コーディング規約) ドキュメント改訂時 データの置き場所が定まったところで、次は AI エージェントがこれらのデータソースをどのような順序で参照し、回答を組み立てるのかを、実際の問い合わせを例に見ていきます。 AI エージェントの推論フロー 「300 台増産は間に合う?」への回答プロセス AI エージェント (Amazon Bedrock AgentCore 上で動作) がユーザーからの問いに答えるプロセスを見てみます。ユーザーが「ORDER-2026-06-001 の増産 300 台は実現可能ですか?」とプロンプトウインドウに入力します。このとき、エージェントは以下の 5 つのステップを実行します。 Step 1 — ナレッジグラフ探索 (Amazon Neptune) オーダーを起点に、ノードタイプごとに異なる情報を収集しながら関係性を辿ります。 ProductionOrder (ORDER-2026-06-001) │ → 数量: 300台、納期: 7/10 │ ├─PRODUCES→ Product (AnyCompany-SD1) │ │ │ ├─REQUIRES→ Part (セラミック素子) │ │ ├─SUPPLIED_BY→ Supplier (セラミック素材社, LT:14日) │ │ ├─STORED_AT→ Equipment (Warehouse Station) │ │ └─PROCESSED_AT→ Equipment (Production Line) │ │ │ ├─REQUIRES→ Part (ブラシレスモーター) │ │ ├─SUPPLIED_BY→ Supplier (モーター工業, LT:21日) │ │ └─ASSEMBLED_AT→ Equipment (Assembly Line) │ │ │ └─REQUIRES→ Part (フライトコントローラー) │ ├─SUPPLIED_BY→ Supplier (エレクトロニクス社, LT:30日) │ └─ASSEMBLED_AT→ Equipment (Assembly Line) │ └─EXECUTED_ON→ Equipment (Production Line, Assembly Line) 1 回の探索で以下が判明します: 部品 3 種 とそれぞれの所要数・リードタイム サプライヤー 3 社 と最小発注数量 関連設備 3 台 の ID(= AWS IoT SiteWise アセット ID) 各ノードに到達するたびに、次のステップで必要な情報 (ID、属性値) が揃います。Part ノードからは在庫確認 (Step 3) に進み、Equipment ノードからはリアルタイムデータ取得 (Step 2) に進みます。グラフが「次にどのデータソースを見るべきか」を教えてくれる構造です。 Step 2 — リアルタイムデータ取得 (AWS IoT SiteWise) Step 1 で特定した設備の ID (= AWS IoT SiteWise アセット ID) を使い、各設備の現在のサイクルタイムと稼働率を取得します。Amazon Neptune のノード ID と AWS IoT SiteWise のアセット ID に同じ UUID を使用しているので、Amazon Neptune のグラフ探索で特定した設備のノード ID を、そのまま AWS IoT SiteWise の API パラメータとして渡しています。別途マッピングテーブルを参照する必要がなく、グラフの探索結果が即座にリアルタイムデータの取得キーになります。関係性は頻繁には変わりませんがサイクルタイムは 1 分ごとに変わり、在庫数量は日々変動します。こうした鮮度の高いデータはそれぞれに適したデータストアに置き、必要なときに ID をキーにして参照するようにしています。 AWS IoT SiteWise 側のアセット階層: AnyCompany (企業) └── Plant 02 横浜工場 └── Line A ├── DSI (受入検査) assetId: d0754657-... ├── VGR (搬送ロボット) assetId: 787a70d9-... ├── HBW (自動倉庫) assetId: 58f6c640-... ├── MPO (加工機) assetId: 2b326756-... ├── FA (最終組立) assetId: 2c26ccc0-... └── DSO (出荷) assetId: d38bb203-... 各アセットは avg_mct (平均サイクルタイム) と Availability_Pct (稼働率) のプロパティを持ち、1 分間隔で更新されます。Step 1 で特定した設備の ID で問い合わせた結果、HBW のサイクルタイムが目標値 (60秒) の 3 倍に達していることが判明します。 Step 3 — 在庫照合 (Amazon DynamoDB) Step 1 で特定した部品の ID を使い、Amazon DynamoDB の在庫テーブルから現在の数量を取得します。BOM の所要数 (×300 台) と比較した結果、在庫は充足していると判断されます。 No. 部品ID 部品名 在庫 所要数 (×300台) 判定 1 PART-CERAMIC-001 セラミック圧力センサー素子 10,000 300 ✓ 十分 2 PART-MOTOR-001 ブラシレスモーター 30,000 1,200 ✓ 十分 3 PART-FC-001 フライトコントローラー 10,000 300 ✓ 十分 Step 4 — 統合判定 Step 2 (設備) と Step 3 (在庫) の結果を突き合わせ、生産能力を評価します。 ボトルネック: VGR + HBW (実測 CT 254.2 秒。タクトタイム 60 秒の約 4.2 倍、稼働率 35%) 在庫リスク: なし (全部品十分) 問題の所在: 部品は足りているが、HBW の処理能力がライン全体のスループットを制約している Step 5 — 自然言語で報告 エージェントが上記を統合し、以下のように自然言語で回答します。 思考過程 ・ユーザーは「ORDER-2026-06-001 の増産 300 台は実現可能ですか?」と聞いています。これは増産指示の実現性診断を求める質問です。 ・生産オーダー情報を取得します。製品名、数量、納期、ステータスを返します。 ・get_production_order 完了 (0.2s) ・Neptune ナレッジグラフを探索して、指定オーダーの影響範囲とボトルネックを検出します。オーダーから製品→部品→設備→サプライヤーの関係性を辿り、在庫不足やサイクルタイム超過を自動検出します。 ・neptune_impact 完了 (0.3s) ・Production Line のリアルタイム稼働データを一括取得 ・get_production_line_metrics 完了 (3.5s) ・部品の在庫情報を取得します。在庫数、安全在庫、リードタイム、サプライヤーを返します。 ・get_inventory 完了 (0.1s) 回答 ■ 影響範囲 (サプライチェーン探索結果) ・対象オーダー: ORDER-2026-06-001(AnyCompany-SD1 ドローン用圧力センサーモジュール 300台、納期 2026-06-13) ・製品: AnyCompany-SD1 ドローン用圧力センサーモジュール ・生産工場: 横浜工場 ・既存バックログ: 200台(合計処理必要数: 500台) ・必要部品と数量: セラミック圧力センサー素子×300、ブラシレスモーター×1,200、フライトコントローラー×300 ■ ボトルネック検出(リアルタイムデータ) ・VGR+HBW(搬送＋自動倉庫): CT 254.2秒(タクト60秒を194.2秒超過、424%)、稼働率 35.0% ・ライン実効CT: 254.2秒/個(ボトルネック律速) ・日産能力: 39台/日 ・5日間生産可能数: 195台 → 横浜工場ダッシュボードで確認 ■ 在庫状況 ・全部品充足(セラミック圧力センサー素子 10,000個、ブラシレスモーター 30,000個、フライトコントローラー 10,000個) ■ 実現性判定 ・間に合いません:5日間で195台しか生産できず、300台に105台不足 ・既存バックログ200台を含めると合計500台必要。達成には13日(約2週間)必要 ・ボトルネックの搬送＋自動倉庫工程(VGR+HBW)がタクトの4.2倍、稼働率も35%と低い 改善策を提案しますか? 参照データソース ・DynamoDB: 生産オーダーテーブル(ORDER-2026-06-001) ・Neptune: ナレッジグラフ(オーダー→製品→部品の関連) ・IoT SiteWise: 横浜工場 Production Line のリアルタイムデータ(サイクルタイム、稼働率) ・DynamoDB: 在庫テーブル(部品在庫状況) (グラフ上で6ノードをハイライト中) なお、この後に続く改善策の提案 — 工程設計書や FMEA を根拠とした運転方法の変更案、PLC プログラムの修正案の生成 — も本デモの見どころですが、紙幅の都合により本記事では割愛します。 全体アーキテクチャ ここまで、ナレッジグラフの設計と AI エージェントの推論フローを解説してきました。このセクションでは視点を引いて、工場の設備からデータを収集し、エージェントが推論するまでを支えるシステム全体の構成を説明します。 本デモは、エッジ (工場) ・IoT データ収集・AI エージェントの 3 レイヤーで構成されています。工場側では 2 系統のデータ経路を持ちます。設備データは PLC → OPC UA サーバー → AWS IoT Greengrass → AWS IoT SiteWise という経路で収集されます。OPC UA は設備のリアルタイム値だけでなくアセット階層(設備間の親子関係や型定義)も標準化された形で公開するため、AWS IoT SiteWise 側でデータストリームとアセット階層の両方を構造化して管理できます。カメラ映像は別系統で、ONVIF 対応カメラ → Raspberry Pi 上の AWS IoT Greengrass → Amazon Kinesis Video Streams に送信されます。カメラの PTZ 制御は AWS IoT Core 経由の MQTT で行い、AI エージェントから操作可能です。 AI エージェントレイヤーでは、Amazon Bedrock AgentCore 上で Strands SDK ベースのオーケストレーターが動作し、問いの種類に応じて専門サブエージェントに処理を委譲します。本記事で解説した実現性診断のフロー (Step 1〜5) は Production Analyst が担当し、カメラ映像による現場確認は Camera Inspector、FMEA など品質文書の参照は QA Manager、制御プログラムの変更案生成は PLC Engineer が担います。各サブエージェントは Amazon Neptune (ナレッジグラフ探索)、AWS IoT SiteWise (リアルタイム値取得) 、DynamoDB (BOP・在庫・オーダー) 、Amazon Bedrock Knowledge Bases (工程設計書・FMEA) 、Amazon Kinesis Video Streams (映像フレーム取得) にアクセスします。 以上が本デモの技術的な全体像です。最後に、実際にブースで来場者の方々と対話する中で見えてきた、実運用に向けた課題を考察します。 全体アーキテクチャ お客様の声と課題 AWS Summit Japan 2026 のブースで製造業のお客様から得たフィードバックのうち、特に多かった 3 点と現時点での見解を共有します。 「関係性を最初に定義するのが大変だ」 — 本デモでは生成 AI に グラフスキーマの定義 を依頼し、一括で生成することで対応しました。「増産診断」というユースケースが明確だったため、必要な関係性の範囲を絞れたことが大きいです。ただし、対象範囲やノード数が拡大した場合に同じ手法でスケールするかは検証が必要です。 「グラフのメンテナンスが大変では?」 — ブースでは「BOM 階層が 100 近くある」という声も戴きました。本デモは数十ノード程度の規模であり、そうした現実のスケールでの変更管理、例えば ERP マスタ変更をイベント駆動で Amazon Neptune に反映するパイプラインなどは今後取り組む必要があります。 「そもそもデータが揃っていない」 — AI エージェント活用デモの多くは参照先データが整備済みの前提で構築されており、本デモも例外ではありません。ただ、本デモは全データをグラフに集約せず、グラフ・IoT・DynamoDB・ドキュメントをそれぞれ別のツールとしてエージェントに持たせる構成にしています。この形だと、新しいデータソースが用意できたときに既存の構成を作り直さず、ツールを 1 つ足すことで対応できます。全体が揃うのを待つのではなく、まず 1 ユースケースに必要なデータから始めて、揃った分だけ段階的に足していく進め方も、選択肢としてあり得るのではないかと考えています。 まとめ 本記事では、AWS Summit Japan 2026「生産ラインの未来」ブースで展示したデモの技術詳細として、製造ドメインのグラフスキーマの設計と、そこに IoT データを接続する方式を解説しました。取り組んだのは「AI エージェントに工場の構造をどう教えるか」というテーマです。製品・部品・設備・サプライヤーの関係を型とエッジとして定義し、Amazon Neptune 上のナレッジグラフに実装しました。サイクルタイムや在庫といった鮮度の高いデータはグラフに持たせず、AWS IoT SiteWise や Amazon DynamoDB から必要なときに参照します。変わりにくい構造と、刻々と変わる値を分けることで、エージェントの回答を速く安定させることを目指しました。一方で、本デモで定義したのは、型（ノード）と、型の間にどの関係が張れるかまでで、その関係自体が従うルールは定義していません。次のステップとして考えられるのは、こうしたルールを RDF/OWL のような形式で記述し、オントロジーへと発展させることです。明示的にリンクを張らなくても不良素材から影響製品を辿れたり、データの矛盾を自動で検出できたりと、対応できる範囲を広げられると考えています。本記事が、製造業のお客様が自社のデータを AI エージェントで活かすための一歩として、参考になれば幸いです。 使用サービス Amazon Neptune — 製造ドメインのナレッジグラフ Amazon Bedrock / Amazon Bedrock AgentCore — AI エージェントの推論基盤 Amazon Bedrock Knowledge Bases — 工程設計書のドキュメント検索 AWS IoT Greengrass — エッジゲートウェイ AWS IoT Core — デバイス接続 AWS IoT SiteWise — 設備稼働データの構造化・蓄積 Amazon Kinesis Video Streams — 工場カメラ映像の管理 Amazon DynamoDB — 生産オーダー・在庫・BOP の格納 著者 新澤 雅治 (Masaharu Niizawa) — IoT Specialist Solutions Architect。製造業、IT 企業を経て AWS に入社。現在は IoT スペシャリストソリューションアーキテクトとして、主に製造業のお客様の Industrial IoT 関連案件の支援に携わる。 松永 充弘 (Mitsuhiro Matsunaga) — Senior Solutions Architect。製造業のお客様を担当するソリューションアーキテクト。クラウド × データ × AI でお客様のビジネスを支援。前職では製造業にて、機器の IoT 化、AI 活用を担当。 関連リンク AWS Summit Japan 2026 ブース紹介 生産ラインの未来 Amazon Neptune — 概要 Amazon Bedrock AgentCore — 概要 AWS IoT Core ー 概要 AWS IoT Greengrass ー 概要 AWS IoT SiteWise — 概要

こんにちは、ラクスでバックエンドエンジニアをしている斉田真也（GitHub: shinya / X: @saita_shinya）と申します。業務のかたわら、Markdownエディタ Bokuchi を個人で開発していて、仕事でも個人開発でも、いまやClaude Codeはすっかり相棒になっています。 先日大阪の梅田で開催された Claude Code Meetup Osaka に参加し、LT枠でも登壇してきました。AIは失敗する。でもその失敗を"使い捨て"にせず記録して次に読ませれば、二度目から同じつまずきを繰り返しにくくなる ── 私が登壇で話したのは、そんな「Claude Codeの育て方」でした。 この記事では当日の様子と学びを、この会ならではの空気感とあわせてレポートします。 TL;DR 大阪・梅田で開催された Claude Code Meetup Osaka に参加し、LT枠でも登壇してきました。 このMeetupは「技術そのもの」より 「業務の困りごとをClaude Codeでどう解いたか」 という一段上のレイヤーの話が中心。並列エージェント・YouTube運営・資料作成など、活用の幅広さに驚かされました。 私のLTは 「失敗を資産に変えるClaude Code」 ── 却下・失敗をログに残してナレッジ化し、 CLAUDE.md のルールだけで"育てる"運用の紹介です。 参加者の層が幅広く、いわゆる技術勉強会より開かれた雰囲気だったのも印象的でした。 目次 TL;DR 目次 結論：ここは「技術の話」より「仕事の困りごとと解き方」の会だった イベント概要 登壇：失敗を資産に変えるClaude Code 登壇資料 大きな知見となった失敗の例 その他の失敗例 勉強になった他の登壇 手塩にかけりゃいいってもんじゃない ── Claude Code 並列エージェント4つの"面倒の見方"（ming さん） Claude Code と回す、YouTube運営のPDCA（masaya_nishigaki さん） 「コーディングだけじゃない」Claude Code活用術（おってぃ さん） 懇親会：「普段AIをみんな、どう使ってるか？」 所感：一段上のレイヤーの話と、参加者層 余談 まとめ 結論：ここは「技術の話」より「仕事の困りごとと解き方」の会だった 普段、言語やフレームワークの勉強会に行くと、どうしても話題は技術そのものに寄りがちです（それはそうですね）。ですがこのMeetupは、 「自分の業務でこんな困りごとがあって、それをClaude Codeでこう解決した」という、一段レイヤーの高い話 が中心でした。 コーディングにとどまらず、マネジメント・広報・YouTube運営まで、活用の幅の広さに驚かされた一日でした。 イベント概要 項目 内容 イベント名 Claude Code Meetup Osaka 日時 2026年6月17日（火）19:00〜21:00 会場 Blooming Camp by さくらインターネット（グラングリーン大阪 JAM BASE 3F） 主催 AI Agent User グループ（AIAU） イベントの流れ 最初にLTの発表→懇親会で交流 余談ですが、会場の場所が最初全然分からず、梅田のグラングリーンをしばらくさまよってからなんとかたどり着きました・・・。新しくできた街の区画は、慣れるまで迷子になりがちですね。同じ会場を目指す方はお気をつけて。 登壇：失敗を資産に変えるClaude Code 私はLTの2番手として 「失敗を資産に変えるClaude Code」 というタイトルで登壇しました。せっかくなので、少しだけ中身を紹介します。 登壇資料 この資料で言いたかったことは全然シンプルな話で、 「AIは失敗する。でも失敗を記録して次に読ませる仕組みがあれば、二度目から同じ失敗を繰り返しにくくなる」 というものです。ここで大事なのは、モデル自体が賢く再学習するわけではないという点です。やっているのは、失敗の理由を外部ファイル（ナレッジ）に残しておき、 次の提案の前に毎回それを読み込ませる という運用の工夫にすぎません。しかもこれを、コードを一切書かずに CLAUDE.md に書いたルールだけ で回しています。 仕組みは大きく5ステップのループです。 自分による依頼をClaudeが受けたら request_log に記録する 自分の反応（「ありがとう」「ちょっと違う」など）から採用/微妙/却下を検知する それを点数（1.0 / 0.5 / 0.0）として evaluation_log に記録する 却下・微妙がついたら、その理由をカテゴリ別のナレッジに1行抽出する 次の提案の前に必ずそのナレッジを読み込む（さらに毎朝GitHubへ自動push） ポイントは、 評価のために特別な操作は何もしない ことです。普段どおり会話しているだけで、その裏で点数がつき、失敗の理由が蓄積されていきます。 3ヶ月ほど運用して、こんな感じの結果になりました。 項目 数 依頼ログ 約240件 ※ 評価ログ 122件 ナレッジ（カテゴリ数） 8カテゴリ うち却下 12回（約1割） ※ 実際のやり取りの回数ではなく、「依頼した仕事」の単位だと思ってください。 却下は12回（約1割）と数としては少ないのですが、 この12回こそが一番の財産 になります。 大きな知見となった失敗の例 この仕組みを使い始めてから、いちばんヒヤリとしたのが、 勝手にcommit & pushまで進んでしまった 件です。作業が一段階済んだ時点で勝手にコミットをして、そのままpushまでClaudeが完遂してしまってました。 別にコード的に問題はなかったので、結果的には大事に至りませんでした。 人間なら「この状態で確定していいかな？」と一度立ち止まって確認する場面です。自分がするときでもそうします。「未確定の情報が現れた時点で相談すべき」という却下は、いま読み返しても一番の教訓になっているなと思います。ただ、その影響で自分が使っているClaudeはなにか作業が終わるたびに「次はあなたが確認する版です。私はコミットはしません」と毎回くどいように言ってきます（笑） その他の失敗例 他にも、以下のような失敗がありました。 頼んでいないのに先に進む ── 「原因は？」と聞いただけなのに、修正コードまで書いてしまった。依頼スコープの越権で却下。 不十分な数字で判断を誤らせかけた ── リポジトリ内で増大するライブラリのサイズを圧縮後の3.1MBだけとClaudeが伝えてきたが、実際は展開後8.2MB。この差が許容できず見送りに。 こうした却下を「その場で直して終わり」にせず、理由をナレッジに1行残して次から回避する。 失敗が使い捨てから資産に変わる 、という話でした。 こうした運用ルールも、失敗ログも、ラクスの業務の中で蓄積されていったノウハウのおかげでもあります。人が失敗したことを繰り返さないようにする仕組みを、AIにも適用したイメージですね。 冒頭で触れた自作の Bokuchi （OSSのMarkdownエディター）の開発を通じてClaude Codeを酷使する中で溜まっていったものも中にはあります。ちなみに、この発表したスライド自体もBokuchiで書いています。個人でこういうツールを作って回せるのも、日々AIに助けられている延長線上にあるなと感じますね。 勉強になった他の登壇 手塩にかけりゃいいってもんじゃない ── Claude Code 並列エージェント4つの"面倒の見方"（ming さん） Claude Codeで 複数のエージェントを同時に起動して処理を任せる ときの実践的なTips集でした。 「並列にすればいいってものじゃない、面倒の見方がある」というタイトルどおり、どこで手綱を握り、どこを任せるかの勘所が、ご本人の経験値とセットで語られていて説得力抜群！これまで基本シングルエージェントで使ってきた自分にとっては、まさに次に試すべき具体的な引き出しが一気に増えた時間となりました。 まさに参加してよかったの一言。 資料: https://speakerdeck.com/ming_ayami/shou-yan-nikakeriyaiitutemonziyanai Claude Code と回す、YouTube運営のPDCA（masaya_nishigaki さん） 驚いたのは、 コマンド一発でエージェントのオーケストレーションが始まる 仕組みでした。 ご自身で運営するYouTubeチャンネルの登録者数を増やすため、目標管理などのマネジメント業務にAIを組み込んでおられて、まるで優秀な秘書に段取りを任せているかのよう。コーディング以外の「運営」領域でここまで回せるのか、というのが一番の発見でした。 チャンネル: https://www.youtube.com/@masayan-ai-hack 「コーディングだけじゃない」Claude Code活用術（おってぃ さん） エンジニアというよりマネジメント側の視点から、 仕様書や各種資料の作成にAIを活用する ノウハウを語られていました。すでにお気づきの方もたくさんおられるとは思いますが、「AIはコードを書く道具」という先入観を、良い意味で外してくれる内容です。開発の現場だけでなくドキュメント業務にも自然にAIが溶け込んでいくのだと、活用の裾野の広さを実感しました。 懇親会：「普段AIをみんな、どう使ってるか？」 LTのあとは懇親会へ。参加されていたエンジニアの方々と交流しながら、自作のBokuchiを紹介したり、みなさんが普段どんな仕事でどうAIを活用しているかを聞いて回りました。 多くは私たちと同じく開発業務での活用でしたが、中には 親子で参加されている方 もいて、日常の中でのちょっとしたツール開発に役立てているという話も聞けました。用途の広がりを実感します。 所感：一段上のレイヤーの話と、参加者層 冒頭で書いたとおり、業務の困りごとベースの話が中心のイベントでした。 その影響もあってか、 参加者の層がとても幅広かった のも印象的です。女性の参加者も多く、エンジニア以外の職種の方や、前述の親子連れの方まで、いわゆる「技術勉強会」のイメージより開かれた雰囲気でした。 会場のBlooming Campは、さくらインターネットさんが運営するコミュニケーションハブのようなイベントスペースで、今回のような勉強会以外にも様々な使われ方ができそうな、可能性を感じる場所でした。 ちなみに、次回の開催が7/10にあるのですが、これにもまた参加（LTも登壇！）してきます。 余談 最後に、この日いちばん予想外だった話をするのですが、私はカードマジック（手品）がとても好きなのですが、会場を提供してくださったさくらインターネットのエンジニアの方の前職が、なんと 手品関係の会社 だったそうで。「その業界からエンジニアへの転職ってあるんだ」と、思わぬところで人の経歴の面白さに触れた一日でした。 まとめ 自分が普段よく参加してる技術一辺倒の勉強会ではなく、「AIをどう仕事の相棒にするか」を各人の実体験ベースで持ち寄る、学びの多いMeetupでした。 並列エージェント、運営へのAI活用、資料作成・・・持ち帰った宿題も色々ありました。運営のみなさま、登壇者のみなさま、会場を提供してくださったさくらインターネットの方々、ありがとうございました。 今回LTで話した「失敗をナレッジに残して育てる」やり方は、もともと自分の業務の中で試行錯誤して形にしたものです。ラクスは複数のプロダクトを抱えていて、チームごとにAIの使いどころも工夫の仕方も違います。そういう各自の工夫を持ち寄って共有できる余地があるのは、個人的に面白がっているところです。こうした社外の学びも持ち帰りつつ、「AIを相棒として育てる」ことを一緒に面白がれる方と、どこかの勉強会でお会いできたら嬉しいです。

初めまして！ NTTドコモビジネス情報セキュリティ部の池山と申します。 未経験からセキュリティ分野に飛び込み、現在は脅威情報を中心に業務を担当しています。 2026年6月13日に開催された「第5回セキュリティ若手の会」にて、ドコモグループ（NTTドコモ・NTTドコモビジネス）はゴールドスポンサーとして協賛し、講演の機会をいただきました。 この記事では、初の外部登壇かつ初参加となった「セキュリティ若手の会」について、ギリギリ若手（社会人3年目）の視点から当日の様子をご紹介します。 セキュリティ若手の会とは？ 当日の様子 LT＆交流会 スポンサー講演登壇 最後に セキュリティ若手の会とは？ 「セキュリティ若手の会」は、将来セキュリティエンジニアを目指す学生や、セキュリティ業務に携わるエンジニアのためのコミュニティとして2024年10月に設立されました。 15歳以上の学生から新卒3年目の社会人までが参加可能となっており、セキュリティに関する技術や業務内容、進路やキャリアについて、直接話し合える機会が提供されています。 このコミュニティの特徴は、「実務志向の話題やキャリアに関する話」と「ユーザー企業・ベンダー企業双方の視点」に重きを置いている点です。 オンライン会場がないため、オフラインイベント（対面）ならではのリアルな話を聞ける場となっており、普段は知る機会の少ない現場の課題や意思決定の背景について理解を深めることができます。 また、若手参加者にとっては、さまざまな立場の方々と交流しながら自身のキャリアを考える貴重な機会となっています。 ドコモグループは、第3回に続き2回目の協賛となります。 協賛にあたっては、ドコモグループの採用担当とも連携しながら、事業内容やセキュリティエンジニアの採用についても広く紹介しています。 セキュリティ若手の会の詳細は以下リンクをご覧ください。 当日の様子 第5回はLT(ライトニングトーク)＆交流会イベントで、東京・日本橋のNICTイノベーションセンターにて開催されました。 学生・社会人あわせて約100名が参加し、テクニカルな話題から就職活動、業務の実情まで、幅広い内容の発表や議論が行われました。 LT＆交流会 当日は6件のLTと、3社によるスポンサー講演、交流会が実施されました。 どのLTも非常にレベルが高く、参加者の皆さんがセキュリティに対して強い好奇心を持ち、知識や技術を深めている様子が伝わってきました。正直なところ少し焦りを感じる場面もあり、身の引き締まる思いでした。 交流会では多くの方とお話しする機会をいただき、業務上の悩みや就職活動の相談、社会人としての心構えなど、若手ならではのテーマについて、学校や会社の垣根を越えて意見交換ができました。 （学生さんの自作名刺がかっこいいデザインのものばかりだったことも非常に印象的でした。すごい。） スポンサー講演登壇 スポンサー講演では、「等身大すぎる業務紹介」をテーマに、NTT Com-SIRTとしての業務をご紹介しました。 学生時代にセキュリティの学習経験がほとんどない状態で入社し、現在CSIRTメンバーとしてどのような業務を担当しているのかを、少しユーモアも交えながら率直にお話ししました。 当日使用した資料はSpeaker Deckにて公開しております。 今回の発表では、自身の経験や業務内容を中心にお伝えする構成としました。 今後は、より技術に踏み込んだ内容も外部で発表できるよう、研鑽を積んでいきたいと考えています。 あわせて、ネットワーキングの場でも話題に困らないセキュリティトークのデッキを増やし、余裕を持って対応できるエンジニアを目指したいと思います。 最後に ドコモグループ（NTTドコモ・NTTドコモビジネス）は、セキュリティ若手の会の活動に賛同し、ゴールドスポンサーとして第5回セキュリティ若手の会の開催を支援しました。 次回のセキュリティ若手の会は2026年10月に開催予定です。 セキュリティ若手の会の公式Xアカウントからぜひ最新情報をゲットしてみてください！ 今回、初めての外部登壇ということもあり、非常に緊張していました。 一方で、創立者の方から「若手が登壇経験を積む場になれば嬉しい」という思いを伺い、この貴重な機会をいただけたことに感謝しています。 今回の経験を糧に、組織のセキュリティ向上にも引き続き貢献していきたいと思います！ 今後も、NTTドコモビジネス情報セキュリティ部ではエンジニアブログを通じて情報発信をしていく予定です。 エンジニアブログのセキュリティカテゴリもぜひご覧いただけますと幸いです。 最後まで読んでいただき、ありがとうございました！^^