ども！ここしばらく、Slidevで作ったスライドをPowerPointで出す方法ばかり検証している龍ちゃんです。 僕は資料を Slidev で書いています。Markdownで書けるので中身がテキストのまま残るし、AIに書かせるのも直させるのも思いのままです。ただ社内に出すとなると、だいたいPowerPointが要求されるんですよね。PowerPointだったら誰でも編集できますもんね。 今回は、コードとして起こしていたスライドをPowerPoint形式にするための検証で、4パターンまで結論が出たのでまとめて紹介しようと思います。 この記事を読み終わると、自分がどの方法を選択するべきかが2つの質問で決まります。そして変換に何を使うかで、その先どこまで行けるかが決まることまで分かるはずです。 AIに資料を作らせるとして、どこまで任せるか 先に断っておくと、会社に出す資料がPowerPointなのは、ここでは前提として扱います。以前「 MarpとSlidevの使い分け 」の最後に「他部署の人が中身を直接いじる用途なら、素直にPowerPointが正解」と書いたんですが、今回はその扉をくぐる話です。 PowerPointじゃなくて、 Claude Design でいいじゃん！とか言わないでください… さて、AIに資料を作らせるといっても任せ方には幅があります。 丸ごと任せる ：手元のソースをそのまま放り込んで、構成から中身まで全部まとめてもらう 変換だけ任せる ：自分で書いた中身を渡して、PowerPointの形にするところだけやってもらう どちらもAIを使っている点では同じ。違うのは、AIをどの工程に置くかだけなんですよね。 丸ごとAIに任せると、何が出てくるのか 過程から見ていきます。 丸ごと任せると、完成品が降ってきます。速いし、出てくるものもきれいです。ただ「なんか違う」となったときに手を入れる場所が途中にない。これは以前「 AIに全任せしないデザインシステムの育て方 」で書いた話で、そのときは「スライドは自分の話しやすさとセットで形になる」という理由を挙げました。今回はもうひとつ別の理由があります。 出てくるものの中身です。 実際に試しました。Slidevのデッキからデザインを落としたMarkdownを用意して、Claude Designに渡して33枚。ここは正直に書くんですが、WEB上で編集までできるうえに、打ち替えられるPowerPointファイルが本当に出ました。文字は395個のテキストとして生きていて、画像は1枚も貼られていない。 見た目はこのとおりで、正直きれいです。 速さも見た目も良かったんですよ。ただPowerPointで開いてみると、403個の図形が全部バラバラに置かれていました。まとまりがないので、このパーツを使いたい、ここだけ動かしたい、となったときの調整が全部人間の手作業になります。PowerPointの強みってそこじゃないですか。掴んで、動かして、組み替える。それができない形で出てきている。 念のため、これは欠陥だと言いたいわけではないです。速いし、デザインもなんとなくきれいに整理されている。用途が違うだけです。ちなみにデザインでいうと提案ベースで出てくるのでClaude Designの圧勝だと思います。 その「用途が違う」というのは、こういうことです。バラバラの図形として出てくると、直すときに一番楽なのはClaude Designの上で直すことになります。つまり正本があちら側へ移る。1回きりの資料なら何も困りませんが、来年また使うとか、会社のテンプレートに載せ替えるとか、他の人が組み替えるとか、難しくなりますよね。 分かれ目はここです。 掴んで動かせる形で欲しいか、そうじゃないか。 社内で共有するのであれば、PowerPointの側に正本を置いておきたいです。そのうえでAIの力は最大限享受したい。なので、Slidevでスライドを作り込んで、最終成果物だけPowerPointに変換するという思想で検証を進めています。なぜSlidevだとAIの力を最大限享受できるのかは後半に書いたので、気になったら読んでみてください。 AIと一緒に、実際どうやってPowerPointにするのか 変換のやり方は4つあります。自分のがどれかは、2つ答えれば決まります。 ひとつめ。会社のPowerPointテンプレートを使いますか。使わない、使いたいけど手元にない、ある、の3つで分かれます。 ふたつめ。作り込んだ図まで持っていきますか。デザインはPowerPoint側で作り込むと割り切って、テキストとスライド割だけ運ぶのか。それとも作り込んだ図まで運びたいのか。この質問は自分のデッキを思い浮かべれば答えられるはずです。 会社のテンプレートを使わないなら 中身を後段の変換器に渡して、PowerPointの形にしてもらいます。会社のロゴも配色も乗りませんが、テキストとスライド割は運べる。 一番簡単なのは、Slidevで書いた中身をそのままClaude Designに貼ることですね。ただ単純に文字編集ができるPPTXの取得が可能になります。 Claude Design側でテンプレートを作って、デザインを均一化する道もあります。こちらは深掘り検証をしてブログにまとめていくので、結論が変わるかもしれません。現時点では、編集はできるけどデザインの修正はClaude Design上でやるのが早い、という中途半端なPPTXが出てくる、という評価です。 会社のテンプレートを使いたいけれど、手元にないなら テンプレートの方を、自分で作ります。 Slidevのテーマには、色もフォントも帯の太さも、手元で表示を確かめながら決めた値がもう書いてあるんですよね。その値を実測して、PowerPointのテンプレートをコードから起こす。デザインを決めるのはHTMLとCSSの世界でやって、決まったものだけをPowerPointへ持ち込む形です。 2026-08-13 PowerPointテンプレが無いなら、Slidevのデザインから自作する 会社のテンプレートがあって、テキストとスライド割だけでいいなら テンプレートが持っているレイアウトを選んで、枠にテキストを入れていく。それだけです。 書式も配置もテンプレート側が持っているので、こちらでは何も指定しません。だから出てくるのは再現ではなく、会社のテンプレートそのものの見た目。代わりに、持っていけるのはテキストとスライド割だけになります。こちらの手法では、デザインに関してはPowerPoint側で担保することになります。 2026-08-13 Slidevの中身を、会社のPowerPointテンプレのレイアウトへ流し込む 会社のテンプレートがあって、作り込んだ図まで持っていくなら 1枚ごとの中身をAIにOOXMLで書かせて、会社のテンプレートと1枚のスライドの上で合体させます。 ロゴやヘッダーのような繰り返し出てくる部分は、テンプレート側に任せたまま。AIが書くのは、その枚にしか出てこない図だけです。出てきた図はカードごとに掴んで動かせます。 2026-08-13 Slidevのスライドを、手で組み直さずに編集できるPPTXにする 4つに上下はありません 念のため書いておくと、この4つに優劣はありません。テキストとスライド割だけを運ぶ道は、図まで運ぶ道の劣化版ではなくて、 デザインはPowerPointに任せると割り切る判断そのものが結論 になっています。 4つともAIを使っていて、違うのはAIをどの工程に置くかだけです。 共通の限界もひとつあります。 HTMLとCSSで作ったものが、そのままの姿で運ばれるわけではありません。 Vue のコンポーネントも凝ったCSSも、変換の過程で落ちます。図まで持っていく道でも、運んでいるのは見た目そのものではなく、AIがPowerPointの図形として書き直したものです。 それと、会社のPowerPoint資料の側しか持っていないなら、この分岐には乗りません。その場合は「 会社のPowerPointの資料をSlidevへ移す話 」へどうぞ。 2026-08-13 PowerPointをSlidevのコードに落とす｜抜くもの、画像に任せるもの 変換に何を使うか Slidevの中身をPowerPointにするとき、変換に何を使うかという話です。 前提を先に置いておくと、 Slidevのpptx書き出し が編集できないのは、Slidevの欠陥ではありません。SlidevはHTMLとCSSをブラウザで描画してスライドにしているので、pptxに書き出すときは描画した結果を画像として貼るしかない。原理的にそうなります。だから出力を後から編集可能にしようとするのではなく、中身の方を別の変換器に渡します。 選択肢は3つあります。簡単な順に並べますね。 Claude Designに貼る。 これが一番簡単で、見た目も一番いい。Slidevで書いた中身をそのまま渡せば、ワンステップで出てきます。ただし出てくる図形はテンプレートの枠に乗らないし、フォントも1文字ずつ直接指定されている。 PPTX側で後からテーマを差し替えても見た目は変わりません。 ここが行き止まりですね。 pandoc を使う。 コマンド1本で終わります。出てくるファイルは図形が全部テンプレートの枠に乗っていて、フォントの指定は1つも書き込まれていない。書式をテーマから継承する素直な形なので、後からテーマを差し替えれば見た目が変わります。渡すのはSlidevの記法を含まない素のMarkdownですね。 python-pptx を使う。 手間は一番かかります。ここだけは自分でコードを書くことになるので、貼るだけ・コマンド1本とは手触りが違います。ただしテンプレを自作する道も、レイアウトへ流し込む道も、合体させる道も、全部これの上に乗っている。 先へ行くというのは、変換にコードを挟む側へ回るということです。 先へ進む気があるなら、これですね。 補足が2つあります。 Claude Designに会社のブランドを載せる道もあります。やることは、会社の .pptx から色やフォントの値を取り出して、それをHTMLとCSSの雛形に起こしてClaude Design側に登録する、という手順です。値が取り出せること自体は「 会社のPowerPointの資料をSlidevへ移す話 」で確かめました。あちらはSlidevへ移す話なので、ここで使うのは取り出しの部分だけです。登録まで持っていくと クラスメソッドさんの事例 の形になります。ただし16種類の雛形をHTMLで起こす手間はテンプレートを自作する道とほぼ同じで、 貼るだけという手軽さは無くなります。 なお成果物はHTMLなので、PowerPointで出したときにどうなるかは僕も試していません。次の検証課題なので、まとめたらブログを追記します！ pandocの方には罠があって、会社のテンプレートを渡してもレイアウトは使ってくれません。 --reference-doc でテンプレートを指定できるんですが、pandocが探しに行くのは Title Slide や Section Header といった英語のレイアウト名。決め打ちです。日本語版のPowerPointで作ったテンプレートは「タイトル スライド」「セクション見出し」のような名前になっているので、1つも一致しない。手元の2つで確かめたら、7枚のレイアウトが全部日本語名で、全部pandocの既定にフォールバックしました。ただし色とフォントは持ってこられます。テーマの部分だけは効くので、ブランドカラーとメイリオの指定は引き継がれました。ロゴも帯も配置も来ませんけどね。 テンプレートを渡せば会社の見た目になる、とはいかない。 pandocが決め打ちで持っている形に、こちら側を合わせにいく作業になります。 ここまでで足りる人も多いと思います。5分や10分のLTとか、社内の共有メモとか。人間が道筋をパッと立てて、どういう展開にするかだけ決めて渡せば、あとはすごくやりやすいですからね。 そういう資料なら、Claude Designに貼るかpandocを通すかで足ります。 それでもSlidevで書き続けるのはなぜか ここから先がある人向けに、僕がなぜSlidevの側に立っているかも書いておきます。 僕にとってSlidevは、資料の正本を置く場所です。色とサイズを縛るCSS変数、よく使うレイアウトと部品、それを使う作法を書いた CLAUDE.md 。この一式を積み上げてきたのが「 SlidevのデザインシステムをCSS変数とCLAUDE.mdで作る 」で、スライドをレビューさせるエージェントも「 3体に分けて 」持っています。資料を作るときはこの仕組みの上に乗るので、けっこう爆速です。 AIには書かせています。ただし丸ごとは任せません。手元で見え方を確かめながら進めたいし、話の展開が文章のまま読めるから、流れが死んでいるのをスライドにする前に見つけられるんですよね。1枚ずつ作り上げながら詰めていく。この進め方そのものは「 AIとスライドを作る進め方 」に書きました。 でも、実際にスライドへ起こしてから見えるものもあるんですよね。論理的には要らないけど、人間が理解するには要る補足とか、たとえ話とか。ああいうものを捕まえられるのは、スライドの形にしたときです。だから流れの設計とスライドの生成は、行ったり来たりできる距離に置いておきたいんですよ。 はっきりさせておきたいのは、 生成そのものは、どちらもAIがやっている ということです。僕がSlidevで書くときもClaude Codeに書かせているので、速さで差がつくわけじゃない。差がつくのは、生成の前と後なんですよね。 後の方は、さっき書いた正本の話です。前というのは、話の流れを組み立てるところ。ひとつ前の章で5分や10分の資料なら貼るだけで足りると書きましたが、45分とか1時間のセミナーになると、話の流れが最初から決まっていることなんて絶対にないんですよね。何を先に置いて何を後に回すか、どこで一度まとめるか・小休止を作るか。そこを行ったり来たりしながら決めていく作業が要ります。僕の仕事にはこの長さの資料が結構あって、だからこの前段が消えません。 まとめ 以前「 Claude Code × Slidev 」で、Slidevのpptx出力について「画像が貼り付けられただけのファイルで編集はできない。配布用の最終形と割り切る」と書きました。配布して見てもらうだけなら、その割り切りは今も正しいと思っています。ただ、そこから先に道があった。中身を別の変換器に渡せば、編集できるPowerPointが作れるんですよね。 そして「 MarpとSlidevの使い分け 」の最後に書いた「他部署の人が中身を直接いじるならPowerPointが正解」という一言も、今回でようやく回収できた気がします。Slidevで書き続けたまま、出口だけPowerPointにする。それが今の答えです。 それと、ここまで読んで「自分は1回きりの資料しか作らないな」と思った人。それでいいと思います。Claude Designに貼れば、たぶん一番きれいなものが一番早く出ます。掴んで動かせる形が要るのは、その資料に先があるときだけです。 なお、変換器の実装をパターンごとの自作から固定化できないか、という論点も検証の中にはあります。ただこちらはまだ設計メモの段階なので、一行だけ触れておきますね。 ここに書いたのは、あくまで僕がこの道で出した結論です。SlidevからPowerPointへ渡すやり方は他にもあるはずで、これが唯一の答えだとは思っていません。 自分の資料がどれくらいの尺で、どこまで先があるのか。そこさえ決まれば、道は勝手に決まります。 ではまた！ ご覧いただきありがとうございます！ この投稿はお役に立ちましたか？ 役に立った 役に立たなかった 0人がこの投稿は役に立ったと言っています。 The post AIは編集しやすいPowerPointスライドを作れるか？ first appeared on SIOS Tech Lab .

はじめに こんにちは、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を相棒として育てる」ことを一緒に面白がれる方と、どこかの勉強会でお会いできたら嬉しいです。