非エンジニアでも、Claude で
AI 駆動開発を始められる

Claude Code は、Anthropic の AI「Claude」を中核にした agentic coding tool（自律的にコードを扱う開発ツール）です。コードベースを読み、ファイルを編集し、コマンドを実行し、開発ツールと統合します。

「補完ツール」ではなく「開発プロセスに入る」

多くの解説は「ターミナルで自然言語からコードを書ける」と説明します。間違いではありませんが、本質はそこではありません。Claude Code は、仕様を読み、既存コードを調べ、実装し、テストし、差分を説明する——開発プロセスそのものに AI が入ります。コード補完の延長ではなく「開発に常駐する実装エージェント」と捉えると、他のコーディング支援との違いが見えてきます。

非エンジニアは「デスクトップアプリ」から

Claude Code はターミナル（CLI）、VS Code / JetBrains、デスクトップアプリ、ブラウザで動き、どのサーフェスも同じエンジンにつながります。コードを書かない人がまず触るなら、ターミナルではなく デスクトップアプリをおすすめします。差分を画面で確認でき、複数のセッションを並べて動かせます（macOS / Windows いずれも提供。利用には有料サブスクリプションが必要です）。

初心者向けノーコードではない

誤解されがちですが、Claude Code は「誰でも雑に作れる」ツールではありません。むしろ設計責任を持てる人ほど効きます。何を作りたいか、どこを変えてはいけないか、何をもって「できた」とするか——を言語化できる人ほど、AI に密度の高い実装をさせられます。

出典: Claude Code 公式ドキュメント（code.claude.com・Lab 最終確認 2026-06-24）。最新の対応サーフェス・料金は公式をご確認ください。

AI 駆動開発の効果は「10 倍速く作れる」と語られがちです。速くなるのは事実ですが、経営にとって本当に効くのは速度そのものではなく意思決定の変化です。従来は要件定義を外すと数百万円単位で痛かった。AI 駆動開発では、小さく作って試し、違えば捨て、当たれば育てる回数を増やせます。変わるのは開発速度ではなく「失敗できる回数」です。

なぜ「今」Claude か

2026 年の競争軸は「コーディング力」から「エージェント制御力」へ移りました。賢い AI があるかではなく、自律して動き続ける仕組みをどう設計するか、が差になります。ここで効くのが、後の章で扱う context・Hooks・サブエージェントといった「境界の設計」です。

事業文脈を持つ人ほど、AI 開発で強い

「非エンジニアでも誰でも作れる」は半分だけ正しい。Anthropic 自身の研究でも、セッションの成否を左右するのはコーディング経験よりドメイン（業務・事業）の専門性で、専門性が上がるほど成功率が上がると報告されています（厳格な判定での verified success が初級 15%・中級以上 28〜33%。これは"事業として成功した割合"ではなく、Claude Code セッション内の研究上の成功判定です）。さらに同研究は「人間が"何を作るか"（計画）の判断の約 7 割を、Claude が"どう作るか"（実装手順）の判断の約 8 割を担う」という分業も示しています。

つまり AI 時代に価値が落ちるのは、コードを書く能力ではありません。事業文脈なしにコードだけを書く能力です。経営者・業務担当者が持つ「何を作るべきか」の判断こそ、AI 駆動開発の燃料になります。

二段で読む

経営者向けに言えば——AI 駆動開発は開発費を下げる話ではなく、新規事業や業務改善の「試行回数」を増やし、意思決定の単価を下げる話です。
開発者向けに言えば——難しくなるのはコードを書くことではなく、責務・状態・権限・データの正本・失敗時の復旧線を先に切ることです。曖昧なまま AI に渡すと、速く壊れます。

出典: Anthropic Research「Agentic coding and persistent returns to expertise」（数値は同研究の報告値・Lab 最終確認 2026-06-24）。

「何が作れるか」を機能で並べると、Web アプリ・社内ツール・チャットボット・API 連携……と、どこの記事とも同じになります。NAL はここを「本番化の壁」で語ります。作れるかどうかより、どこまで本番に近づけられるかが重要だからです。

以下は、公開できる範囲で紹介する NAL の実運用例です。顧客データや内部構成の詳細は伏せ、設計上の論点に絞って紹介します。

実例 1｜Kokai Data — AI が使うデータ基盤を「製品」として設計する

法人情報・補助金・法令・統計・入札などの公開情報を、出典つきの AI-Ready なデータに変換し、MCP サーバー経由で外部の AI エージェントから利用できるようにしたプロダクトです。MCP（AI に外部データを接続する公開規格）を「流行りの連携機能」としてではなく、自社のデータと業務文脈を、AI が安全に参照できる形へ整える設計問題として扱った点が肝でした。

実例 2｜GoOCR — 精度だけでなく「保持しない設計」

PDF・画像・スキャンを、縦書きや図表も含め構造を保ったまま Markdown 等に変換する AI OCR です。OCR のデモは簡単です。難しいのは、顧客の文書をどう扱い、どこに保存せず、どこで破棄し、どう課金し、失敗時にどう説明するか。GoOCR の原文非保持設計は、機能ではなく設計思想です。ここでいう非保持とは、利用者がアップロードした原文ファイルをサービス側で長期保管しない設計を指します（変換結果・課金や利用ログ・外部 API の処理条件は別途設計・規約確認が必要です）。原文を保持しない設計は、機密文書を扱う用途で重要な前提になります。

実例 3｜自社 CRM / メール基盤 — 地味な業務基盤こそ最短で内製化

本当に事業に効くのは、派手な AI チャットより、その後ろにあるリード管理・同意 trail・配信停止・通知・運用導線だったりします。NAL は自社の CRM とメール基盤を AI 駆動で内製化しました。AI 駆動開発の実力は、派手な生成 AI 機能ではなく——「AI っぽくない周辺業務」をどれだけ速く固められるかに出ます。

3 つの実例を「Lovable × Claude Code」で見る

普通の入門は「インストール → リポジトリを開く → CLAUDE.md を書く → コマンドを打つ」と進みます。NAL の出発点は違います。最初に決めるべきは Claude Code の使い方ではなく——何を 1 単位として AI に任せるかです。

まずはデスクトップアプリで

非エンジニアなら、ターミナルではなくデスクトップアプリから始めるのが近道です。差分を画面で確認しながら、日本語の指示で進められます。インストール手順は公式に整っているので、ここでは深追いしません（本ガイドの目的は「手順」より「進め方」です）。

Lovable で形を作り、Claude Code で本番化する

Lovable と Claude Code は競合する道具ではなく、役割が違います。Lovableは業務担当者が画面・導線・業務フローを短時間で形にする入口。Claude Codeは、その試作を本番に近づけるために、データ構造・認証・権限・API・テスト・運用導線を固める開発エンジンです。NAL はこの 2 つを分断せず、業務の仮説検証から本番化までを一つの流れとして扱います（前者の解説は姉妹ページ /lovable）。

1. Lovable業務画面を立ち上げる — 非エンジニアが業務要件を画面・導線として表現する
2. Claude Code構造を固める — DB・認証・RLS・API・テスト・エラー処理・運用導線を設計する
3. Lovable体験を調整する — 画面文言・導線・レスポンシブ・フォーム体験を詰める
4. Claude Code本番ガードを締める — 受け入れテスト・セキュリティ・ログ・rollback・docs を固める

NAL 式・AI 駆動開発の 5 段階

本番で崩れない開発には、実装の前に決めることがあります。NAL は次の順番で考えます。自分で進める場合も、この順で考えると事故が減ります。

1. 01目的を 1 文にする — 「何を作るか」でなく「何が実現するか」。例：「問い合わせフォームを作る」でなく「深夜・休日のリードを取りこぼさず、同意 trail と自動返信まで残す」。
2. 02SoT（正本）を決める — どのデータが正本か（DB / URL / 外部 SaaS / docs）。AI に渡す前に、人間がここを決める。
3. 03変更しない領域を決める — 「何を変えるか」だけ渡すと、AI は良かれと思って余計な所まで触る。本番では「何を変えないか」の方が重要。
4. 04受け入れテストを先に書く — 実装させる前に、ユーザー体験・ガード・回帰を固定する。
5. 05実機で閉じる — grep / diff だけで終わらせず、実際の画面・通信・データの中身まで見て確認する。

「最初の 100 時間」より「最初の 1,000 時間」の設計

Claude Code をうまく使う鍵は、長く使うほど効いてきます。常時読み込まれる CLAUDE.mdには「広く当てはまること」だけを書き、たまにしか要らない手順は Skills（必要時のみ読み込む再利用ワークフロー）に分け、独立した探索はサブエージェントに渡して文脈を分離する——この「育て方」が、半年後の生産性を決めます。

ここは上級者向けの核心です。世の中は「AI エージェントが自律的に開発する」と語りがちですが、本番運用の側から見ると、勝負は別のところにあります。自律性を上げれば賢くなるのではありません。境界が曖昧なまま自律性を上げると、速く壊れます。

コンテキストは「消耗品」ではなく「設計の主軸」

公式のベストプラクティスは、勘所の多くがたった一つの制約に由来すると述べています——「コンテキストウィンドウはすぐ埋まり、埋まるほど性能が落ちる」。何でも読ませれば賢くなるのではなく、今回の判断に必要な正本（SoT）だけを渡す設計が効きます。CLAUDE.md（常時ロード）と Skills（必要時のみ）を使い分け、サブエージェントで文脈を分離し、巨大タスクは「レビューできる単位」に割る。これは精度であると同時に、コストの設計でもあります。

Hooks は「法律」、CLAUDE.md は「助言」

CLAUDE.md に書いたルールは、AI が「参照する助言」であって強制ではありません。確定させたいガード（自動整形、危険操作の遮断、テスト実行）は Hooks（イベントで決定論的に走る仕組み）で固定できます。ただし全ての hook が動作を遮断できるわけではなく、止めたい操作は事前（Pre）フックや権限設定、CI / テストのゲートと組み合わせます。プロンプトで「お願いする」のと、機構で確実に走らせるのは別物です。

「人間が承認すれば安全」ではない

承認は流れ作業になりがちで（approval fatigue）、危ないものも通ります。だから自律性を上げるほど、権限・境界・失敗時の復旧線を先に設計する必要があります。エージェント開発の本質は、AI を自由にする技術ではなく——AI を安全に「不自由」にする設計です。

同じ失敗を二度しない仕組み

AI 駆動開発で効くのは、失敗しないことより「同じ失敗を繰り返さない仕組み」です。NAL では失敗を memory 化し、受け入れテストや CLAUDE.md のルールに昇格させ、次回のゲートに変換します。そして GO / NO-GO を曖昧にしない。「だいたい良さそう」で進めることが、AI 開発で最も危険です。

経営者向けに言えば、これは「AI に任せる範囲」と「人間が承認する境界」を決める内部統制の話です。開発者向けに言えば、プロンプトではなく実行前後のゲートで品質を担保する話です。

参考: Claude Code ベストプラクティス・Hooks 公式ドキュメント・Anthropic「How we contain Claude」（Lab 最終確認 2026-06-24）。

最後に、いちばん正直な章です。NAL に頼むべきかどうかは、技術力ではなく「失敗コスト」で決めるのが正解です。「まずはご相談ください」では弱い。だからはっきり分けます。

NAL の役割

NAL の役割は、Claude Code を代わりに叩くことではありません。プロダクト・マーケティング・経営・業務設計・実装・運用を、一つの判断として束ねることです。外部に頼む価値は、手を動かしてもらうことより——どこまで自社で持つべきかを設計することにあります。

NAL と進める場合、最初に作るのは「コード」ではありません。本番化できる範囲・避けるべき範囲・最初の Unit・データの正本・受け入れテスト・運用上の注意点を 1 枚に整理します。最初の成果物は、たとえば次のようなものです。

• AI 駆動開発の対象業務マップ
• Lovable / Claude Code / 人間の分担表
• 最初の Unit 定義と SoT（正本）
• データ境界・権限の設計メモ
• MVP から本番化までの実装順序
• リスクと専門家確認が必要な領域