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

Claude Code（Anthropic）と Codex（OpenAI）は、どちらもコーディングエージェント（自律的にコードを扱う開発ツール）です。コードベースを読み、ファイルを編集し、コマンドを実行し、結果を確かめるところまで進めます。

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

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

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

どちらもターミナル（CLI）、エディタの拡張機能、デスクトップアプリ、ブラウザから使えます。コードを書かない人がまず触るなら、ターミナルではなくデスクトップアプリをおすすめします。差分を画面で確認でき、複数の作業を並べて動かせます。Claude Code は Claude のデスクトップアプリ（macOS / Windows。Linux はベータ。利用には有料プランが必要です）、Codex は ChatGPT のデスクトップアプリ（macOS / Windows / Linux）の中で使えます。

名前は違っても、部品はよく似ている

2 つの道具は別の会社の製品ですが、役割が同じ部品を持っています。だから本ガイドは、どちらか一方の操作方法ではなく、どちらにも通用する進め方を扱います。

Claude Code は、リポジトリに CLAUDE.md が無く AGENTS.md だけがある場合、それを指示書として読みます。両方を置く場合は、CLAUDE.md から AGENTS.md を読み込む形にすれば、同じ指示を二重に書かずに済みます。

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

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

出典: Claude Code 公式ドキュメント・同（指示書の読み込み）・Codex 公式ドキュメント（Nihonbashi AI Lab 最終確認 2026-10-06）。対応する画面・OS・料金は変わるので、最新は公式をご確認ください。

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

道具選びより「制御」が差になる

2026 年の競争軸は「コーディング力」から「エージェント制御力」へ移りました。賢い AI があるかではなく、自律して動き続ける仕組みをどう設計するか、が差になります。どの道具が優勢かは数か月で入れ替わります。入れ替わっても残るのは、後の章で扱うコンテキスト・Hooks・サブエージェントといった「境界の設計」です。

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

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

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

二段で読む

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

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

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

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

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

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

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

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

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

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

3 つの実例を「Lovable × コーディングエージェント」で見る

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

どちらから始めるか

迷ったら、すでに契約している側から始めてください。Claude の有料プランがあるなら Claude Code、ChatGPT を使っているなら Codex です（Codex は ChatGPT の各プランに含まれ、使える量はプランで変わります）。どちらも、ターミナルではなくデスクトップアプリから始めるのが近道です（1 章）。インストール手順は公式に整っているので、ここでは深追いしません。進め方は共通なので、後からもう一方を足しても学び直しは小さく済みます。大事なのは道具の優劣より、次の節から扱う「任せ方」です。

Lovable で形を作り、コーディングエージェントで本番化する

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

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

Nihonbashi AI Lab 式・AI駆動開発の 5 段階

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

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

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

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

出典: Codex 公式ドキュメント（料金）・Claude Code ベストプラクティス・Codex 公式ドキュメント（AGENTS.md）（Nihonbashi AI Lab 最終確認 2026-10-06）。

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

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

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

Hooks は「法律」、指示書は「助言」

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

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

承認は流れ作業になりがちで（approval fatigue）、危ないものも通ります。だから自律性を上げるほど、権限・境界・失敗時の復旧線を先に設計する必要があります。どちらの道具も、触れる範囲を OS レベルで絞るサンドボックスを備えています（Codex は既定でネットワークを切った状態で動きます）。エージェント開発の本質は、AI を自由にする技術ではなく——AI を安全に「不自由」にする設計です。

作った AI に、自分の仕事を採点させない

AI は、自分が書いたばかりのコードに引きずられます。Claude Code の公式ベストプラクティスも、新しい文脈で読ませた方がレビューの質が上がると述べ、作業した当人に採点させない「第二の意見」を勧めています。私たちはこれを一歩進めて、別の会社の AI に確かめさせます。Claude Code で作ったものは Codex に、Codex で作ったものは Claude Code に読ませます。作った本人と同じ癖を持たない目で確かめるためです。2 つの道具を併用すると、この形が取れます。

同じ資料は注意点も挙げています。穴を探せと頼まれたレビュアーは、問題が無くても何かを報告します。指摘を全部直すと作り込みすぎになるので、正しさと要件に関わるものだけを拾い、残りは任意とします。進め方の実際は、ブログ「AI 同士がレビューし合う」に書きました。

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

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

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

参考: Claude Code ベストプラクティス・Claude Code Hooks・Codex Hooks・Codex の承認とセキュリティ・Anthropic「How we contain Claude」（Nihonbashi AI Lab 最終確認 2026-10-06）。

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

Nihonbashi AI Lab の役割

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

進め方は 2 つあります。仕組みづくりから一緒に進める 業務システムの内製化支援と、月額で相談しながら進める AI 導入支援です。

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

• AI駆動開発の対象業務マップ
• Lovable / コーディングエージェント / 人間の分担表
• 最初に任せる 1 単位と、データの正本
• データ境界・権限の設計メモ
• 最初の版から本番化までの実装順序
• リスクと専門家確認が必要な領域