Claude CodeとVibeCoding——製造業DXで「動くシステムを1日で作る」が現実になった
「コードが書けなくていい」という話は、2025年からずっと言われてきました。だが正直なところ、半信半疑でした。2026年6月、Anthropicが最新モデルClaude Fable 5を一般公開したとき、その半信半疑がようやく消えた気がしています。
私たちAI-PathはFDE(フォワードデプロイドエンジニア)として製造業の現場に入り、顧客の目の前でシステムを作り続けてきました。その中でClaude Codeは、単なる便利ツールではなく、「どうやって顧客に価値を見せるか」のスピードを根本から変えるものになっています。製造業のDXや、業務システムのAI開発内製化を検討している方に向けて、現場の体験をそのままお伝えします。
この記事では、製造業DXの現場でClaude Codeをどう使っているか、何が変わって何が変わっていないかを報告します。概念の解説よりも「実際に何が起きているか」を中心に据えました。
- 01「これって、本番で使えるの?」と聞かれた日
- 02Claude Codeとは何か——AIがコードを書き、テストし、コミットまで担うツール
- 03Claude Fable 5で何が変わったか——2026年6月、VibeCodingが次の段階へ
- 04私たちが使っている「製造業×Claude Code」の実践パターン
- 05AI開発内製化で陥りやすい3つの落とし穴
- 06向かない場面も正直に言う——Claude Codeの限界と付き合い方
- 07「どこからでも仕事ができる」は正確ではない——AI疲れとの折り合い
- 08FDEとしてのClaude Code——「道具」ではなく「橋」として使う理由
- 09よくある質問
- 10「AIを道具にする」組織と「AIに使われる」組織の分岐点
- 11まず試すなら
- 12筆者プロフィール
- 13参考リンク
「これって、本番で使えるの?」と聞かれた日
先日、ある大手化粧品メーカーの生産管理担当者と打ち合わせをしていたときのことです。議題はAI活用の方向性でしたが、話が進むうちに担当者の方がA4の紙を取り出し、手書きのスケッチをテーブルに置きました。「こういう画面があったら、毎朝の在庫チェックが10分で終わるんですよね。でも開発部門に頼んだら半年待ちって言われて」。
私はノートパソコンを開き、Claude Codeに向かって話しかけました。「生産管理のダッシュボードを作りたい。製品ごとの在庫をリアルタイムで表示して、最低在庫を下回ったらアラートを出す機能が欲しい。バックエンドはSupabaseを使う。まずUIの骨格から作ってほしい」。
Claude Codeはファイルを作り始め、コードを書き、不明な部分を私に質問しながら進んでいきました。打ち合わせの合間に指示を重ね、1時間後には動くプロトタイプが手元にありました。
担当者の方は少し沈黙してから聞きました。「これって、本番で使えるの?」
この問いは2026年における開発の本質を突いています。答えは「条件次第でYES」です。プロトタイプが動くことと、本番環境で安定稼働することは別の話——だが今まで「半年かかる」とされていた最初の一歩が、1時間で踏めるようになった。この変化は、製造業の現場でAI開発内製化を進める上で、想像以上に大きな意味を持っています。
担当者が「自分の要望を具体化できる」段階に来た瞬間、プロジェクトの意思決定スピードが別次元になります。私たちはこの体験を、製造業の現場で何度も繰り返してきました。
Claude Codeとは何か——AIがコードを書き、テストし、コミットまで担うツール
Claude Codeは、Anthropicが提供するターミナルベースのAIコーディングエージェントです。端的に言えば、「自然言語で指示を出すと、ファイルを読み書きし、コマンドを実行し、GitHubにコミットするところまで一人でやってくれる」ツールです。
従来のAIコーディング支援ツールは「コードを提案する」ものでした。コードを受け取って修正するのは人間の役割だった。Claude Codeはその前提を変えました。プロジェクト全体のコンテキストを把握した上で、ファイルを横断して修正し、テストを実行し、エラーを自己修正する——この「エージェント的」な動き方が、VibeCodingを現実に近づけた最大の要因だと考えています。
Cursorなど他のAIコーディングツールとの違いを聞かれることがあります。大まかに言えば、Cursorはエディタ(IDE)として使うもので、Claude CodeはCLI(コマンドライン)から動かすものです。どちらが優れているというより、使い方が違う。私たちの現場経験では、顧客の既存コードベースにFDEとして入り込む場合、Claude Codeのほうがプロジェクト全体の把握力が高く、指示の通りが安定していると感じています。
もう一つ重要なのは「コンテキスト窓の使い方」です。Claude Codeはプロジェクト全体を読み込んだ上で作業するため、「あのファイルの変数をこっちのファイルでも使いたい」という横断的な変更が、人間が一々ナビゲートしなくても通ります。業務システムの開発では、データモデルやAPI設計が複数ファイルにまたがることが多く、この点でのアドバンテージは実務レベルで体感できます。

Claude Fable 5で何が変わったか——2026年6月、VibeCodingが次の段階へ
2026年6月9日、AnthropicはClaude Fable 5を一般公開しました。これは同社が「Mythos」と呼んでいた最上位モデルをより広く使えるようにしたもので、悪用を防ぐ保護機能を備えた上での公開となっています。
実際に使ってみて感じた変化は主に3点です。
1つ目は長文脈での一貫性。大きなコードベースに対して複数のファイルを横断した修正指示を出しても、意図がぶれにくくなりました。従来モデルでは「最初の指示を忘れる」ような挙動が起きることがありましたが、Fable 5ではその頻度が明らかに下がっています。
2つ目はツール呼び出しの精度。ファイルの編集や削除、コマンド実行の判断が的確になりました。「間違ったファイルを消した」「意図しないブランチにコミットした」といったミスが減りました。
3つ目は曖昧な指示への対処。「いい感じにして」という指示でも、文脈から意図を読んで合理的な実装を選ぶようになっています。完璧ではないですが、以前より「確認なしに突き進んで後で修正する手間」が減っています。
ただし正直に言えば、VibeCodingの体験が劇的に変わったかというと、変化は「量」よりも「安定度」の向上です。できることが新しく増えたというより、以前できていたことがより再現性高くできるようになった——そういう印象があります。「これはもう使える」と判断できる場面が増えたのが、Fable 5の本質的な変化です。
私たちが使っている「製造業×Claude Code」の実践パターン
AI-PathがFDEとして製造業DXの現場で使っているClaude Codeの活用パターンを紹介します。いずれも実際の案件(NDA範囲内で匿名化)を元にしています。
パターン1: 打ち合わせ中にプロトタイプを作る
先ほどの化粧品メーカーの事例がこれです。顧客が「こういうものが欲しい」と言った瞬間に、その場でClaude Codeに指示を出します。目的は「完成品を作ること」ではなく、「顧客が自分の要求を具体化するための壁打ち相手を用意すること」です。動くプロトタイプがあると、「実はここが違う」「この機能はいらない」という本当の要求が出てきます。要件定義と初期開発が同時に進む、という感覚に近い。
パターン2: 既存業務の自動化スクリプトを即座に作る
ある大手建材メーカーのプロジェクトでは、設計部門が毎日Excelでこなしていた「図面からの部品拾い出し作業」をAIに置き換えるシステムを構築しました。Claude Codeにデータ形式とロジックを説明すると、処理スクリプトの初版を数分で作ります。その後FDEが確認・調整し、顧客のエンジニアと一緒に本番環境に組み込んでいく。この「初版を人間が書かない」というだけで、プロジェクトの立ち上がりが体感で3倍速くなっています。
パターン3: 顧客エンジニアの技術移転ツールとして使う
中堅製作所との案件では、顧客側のエンジニアがClaude Codeを使えるようにすることも目標の一つでした。私たちがFDEとして入っているうちに、顧客エンジニアが「自分でもClaude Codeに指示を出して修正できる」状態を作る。これが本当の意味での技術移転です。報告書を残すのではなく、「現場の人が自走できる能力」をシステムと一緒に残す——これがAI-PathのFDEとしての役割です。

AI開発内製化で陥りやすい3つの落とし穴
製造業でAI開発内製化を進めようとする企業が、Claude Codeを導入した後に直面するパターンがあります。私たちが現場で見てきたものを3つ挙げます。
落とし穴1: 「とりあえず触らせる」戦略の失敗
「エンジニアにClaude Codeを渡したら自然に使いこなすはずだ」という期待は、7割のケースで裏切られます。Claude Codeは強力なツールですが、「何を作るか」を自分で設計できない人間には、ツールの強さが逆に邪魔になります。曖昧な指示に対してそれらしいコードが出てくるため、「うまくいっている気がする」段階が続き、後になって「実は全然違うものができていた」と気づく。
落とし穴2: コードレビューの省略
Claude Codeが生成したコードは、読めば理解できる品質です。だからこそ「とりあえず動いているからいいか」という判断が起きやすい。特に製造業では、動作環境の前提(特定の機種のブラウザしか使えない、等)やセキュリティ要件がシステムによって異なります。AIが書いたコードを読む習慣を組織として設計しておかないと、後になって重大な問題が出てきます。
落とし穴3: 「AI頼みの指示」が蔓延する
Claude Codeを使い始めると、「AIに全部任せれば早い」という感覚が出てくることがあります。これが蔓延すると、業務知識のある人間が要件の言語化から離れ始めます。結果として、誰も全体設計を把握しないシステムが生まれる。AIはあくまで実装の担当者であり、「何を作るか・なぜ作るか」を考えるのは人間です。この役割分担が曖昧になるのが最大のリスクです。
向かない場面も正直に言う——Claude Codeの限界と付き合い方
ここまで読むと「万能ツールだ」と思われるかもしれません。そうではありません。私たちの現場経験では、Claude Codeが明らかに不向きな場面があります。
大規模な既存コードの全面リファクタリングは向きません。長年積み上げてきた複雑なコードベースに対して「全部きれいにして」という指示は、意図しない場所を壊すリスクが高い。小さな範囲に絞って段階的に進めるのが現実的です。
精密な数値演算や統計処理も苦手です。LLMは数学の厳密さを保証できない。品質管理の判定ロジックや需要予測の計算式など、数値の正確性が命取りになる部分は、人間が設計してClaude Codeには実装の「骨格」だけを任せるべきです。
ミッションクリティカルなシステムの単独作業には使いにくい。医薬品の製造管理や安全に関わるシステムなど、バグが人命に関わる場合は、AIが生成したコードを別の人間がレビューする体制が前提です。Claude Codeが書いたコードは、人間が読んで確認することを原則とする——これは崩さないほうがいい。
AIは壁打ち相手であり、判断は人間がする、というのが私たちの一貫したスタンスです。Claude Codeを使い始めたばかりの方が陥りやすいのは、「AIが作ったから大丈夫」という過信です。ツールが優秀になればなるほど、この過信は危険になります。
「どこからでも仕事ができる」は正確ではない——AI疲れとの折り合い
AIエージェントを使って場所を問わずに仕事できる環境を整えたものの、気づいたら疲弊してやめてしまった——こういう体験談が2026年に入ってから増えています。
この問題意識は私たちの実感とも重なります。Claude Codeは確かに強力ですが、使い続けると「AIを管理する仕事」が増えてきます。セッションが長くなるほどコンテキストが膨らみ、指示の通りが悪くなる。方向性がずれたまま進んでしまって、後で大量に修正するはめになる——こういう経験をした人は多いはずです。
私たちが行き着いたのは「1タスク=1セッション」というシンプルなルールです。新しい機能を作るとき、バグを直すとき、それぞれ新しいセッションで始める。長いセッションを継続するよりも、短いセッションをはっきりした目的で繰り返すほうが、結果的に速い。
もう一つは「指示の質が成果の質を決める」という認識です。曖昧な指示を出すと、AIは「それっぽいもの」を作ります。製造業の現場であれば、在庫の単位、アラートの閾値、担当者の権限設計——こういった業務の具体を最初の指示に盛り込むかどうかで、手戻りの量が全く変わります。Claude Codeを使いこなすには「何を作りたいか」を人間がきちんと言語化する力が求められます。AIは「何を作るか」の判断を代替しない。
FDEとしてのClaude Code——「道具」ではなく「橋」として使う理由
AI-PathがClaude Codeを位置づけているのは、単なる開発ツールではなく、「FDEが顧客の現場に価値を届ける速度を上げる橋」です。
コンサルタントは提案書を書いて終わります。SIerは仕様書を受け取って数ヶ月後に納品します。FDE(フォワードデプロイドエンジニア)は顧客の現場に入り、本番コードを書き、成果まで責任を持つ——この違いは「スピード」で最も鮮明になります。打ち合わせの場でプロトタイプを作れる。翌週には改善版を持っていける。現場の担当者が「使えそうだ」と判断する前に、実際に使える状態にする。Claude Codeはこのサイクルを支えるツールです。
私たちの現場経験では、「AIを入れたい」という顧客の多くが、実は「何に使えるかよく分からない」という状態にいます。業務の何をAIに任せるかは、現場を見ないと分からない。だから私たちはまず現場に入り、担当者と話し、その場でClaude Codeを使って「こういうことができる」を見せます。百の説明より一つの動くプロトタイプが、意思決定を速める。これがFDEとしての仕事の核心です。
VibeCodingが「コードを書けない人が作れる」という話で広まりましたが、製造業DXの文脈では少し違う意味も持っています。コードを書けるエンジニアが、現場の業務知識を持った担当者と一緒にリアルタイムで作っていける。専門知識と技術の距離が縮まる——これがClaude Codeがもたらした変化の中で、私たちが最も大きいと感じているものです。
AI開発内製化と製造業DXは、もともと「別々の専門家が担うもの」とされてきました。業務改善の専門家と、システム開発の専門家が、別々の立場から関わる構造です。Claude Codeはこの構造を揺さぶっています。業務知識のある担当者がシステムの設計に直接関われる、エンジニアが業務の文脈を理解しながら即座に実装できる——この双方向の距離の縮まりが、製造業DXを加速させる本質的な力です。
よくある質問
Q: CursorなどほかのAIコーディングツールとの違いは?
Cursorはエディタとして使うもので、Claude CodeはCLIから動かすものです。どちらを選ぶかはチームの好みと用途次第ですが、私たちは顧客の現場でのプロトタイプ作成にはClaude Code、自社開発の日常業務にはCursorを使い分けています。
Q: セキュリティへの配慮は必要ですか?
はい、必要です。Claude Codeはデフォルトでファイルを読み書きするため、機密情報を含むプロジェクトで使う場合は設定の確認が前提です。製薬・化粧品のR&Dのような機密性が高い領域では、ローカルLLMとの組み合わせも検討しています。
Q: 月の費用はどのくらいかかりますか?
Claude Code自体の利用はAnthropic APIのトークン従量制です。私たちの使い方(製造業案件で複数メンバーが使用)では月あたり数万円程度になることが多いです。1日でプロトタイプが作れる開発速度と比較すると、対費用効果は高いと評価しています。
Q: 非エンジニアでも使えますか?
Claude Codeそのものはターミナルの基本知識が必要で、完全な非エンジニアには難しい側面があります。VibeCodingの入口としては、CursorやLovableなどGUIで操作できるツールからはじめるほうがスムーズです。VibeCodingの概念から理解したい方は、VibeCodingとは何かの記事もあわせてご覧ください。
Q: 製造業以外の業種でも使えますか?
もちろんです。ただし私たちの現場経験は製造業が中心なので、この記事では製造業に絞ってお伝えしました。AIエージェントが企業システムを変えるの記事では、製造業以外の業種での活用についても触れています。
「AIを道具にする」組織と「AIに使われる」組織の分岐点
Claude Codeのような強力なツールが一般開放された2026年、製造業の現場では静かな分岐が起きています。同じツールを手にしながら、それを「道具として使いこなす」組織と、「なんとなく使っている気がするが実態は変わっていない」組織の間で、差が広がっています。
私たちが現場で見てきた「道具として使いこなしている」組織には、共通する特徴があります。まず、AIにどの業務を任せて、どの判断は人間がするかを、明文化している。次に、Claude Codeが生成したコードを読んで理解できる人間がチームに1人以上いる。そして、「AI開発内製化のゴール」を「ツールを使えるようになること」ではなく「現場の課題が解決される状態」に置いている。
逆に、定着しない組織のパターンは「ツールを試す段階で終わる」です。Claude Codeをインストールして、何かを作ってみて、「なるほど面白い」と思う。でもそこで止まる。製造業DXの文脈でAI活用を進めるには、「試す」から「業務に組み込む」への移行をどう設計するかが鍵です。
FDEとして現場に入る私たちの役割は、この移行を一緒に設計することです。ツールの使い方を教えるだけではなく、「この業務にはClaude Codeを使う、この判断は人間が取る」という役割分担を、実際に動かしながら作っていく。これが、導入後に形骸化しないAI活用の条件です。
まず試すなら
1. まずClaude Codeをインストールして「自分の業務」で使ってみる
いきなり本番プロジェクトではなく、自分が毎日使っているExcel集計やレポート作成を、Claude Codeに「Pythonスクリプト化して」と頼んでみてください。完璧でなくていい。「使えそうだ」という感触をまず掴むことが先です。
2. 「何を作るか」を言語化する練習をする
Claude Codeへの指示は自然言語ですが、「いい感じに」では動かない。製造業であれば「どの業務の、どのデータを、どういう形で処理するか」を30秒で説明できるレベルの言語化が求められます。AI開発内製化を進める上で、この言語化の力が全ての土台になります。
3. 自社の現場でどこに使えるか、一緒に考えてみる
AI-Path では、無償の業務プロセス診断(BPR)を実施しています。製造業DXの現場でAIが効く業務はどこか、Claude Codeでどこまでの内製化が現実的かを、私たちが一緒に整理します。まずはお気軽にご相談ください。
筆者プロフィール
櫻井文雄 / 株式会社AI-Path 代表
関西大学法学部法律学科卒業。財務コンサルティング会社(エフアンドエム)、外資系生保営業(Prudential)でコンサルティング営業の経験を積んだ後、起業し様々な企業のCTO/CMOを歴任。その後、デロイトトーマツコンサルティング(Big4)、ABEJA(AI研究開発の国内リーディングカンパニー)にて官公庁・製造業・金融業・小売業・不動産業を中心に延べ20社以上のDX推進や業務システム刷新をPM/SMとしてリード。利用者目線での現場の課題解決にフォーカスしたものづくりに拘り、導入ではなく「定着化」を目的とした伴走型のプロジェクト推進・システム導入を得意とする。 2025年にAI駆動開発(VibeCoding)と出会い、より多くの人・企業に価値提供するためにAI-Pathを創業。
参考リンク
「Claude Code」を支える技術(Zenn / ナレッジセンス) — Claude Codeのアーキテクチャをソースコードレベルで解析した技術記事。
どこからでもAIで仕事をできるようにしたけど、疲れてやめた話(Zenn) — AIエージェントを使った非同期ワーク体験と、その限界についての体験談。
Anthropic、最上位モデルを一般提供 「Claude Fable 5」(ITmedia) — Claude Fable 5公開と保護機能に関するITmediaの報道。