Claudeと開発ツールの地図

1. 全体像

Webサービスを作って公開するまでは、4区間の1本道

ツール名が覚えられないのは、それぞれが「道のどこを担当しているか」がわからないからです。順番に並べると4つしかありません。

2. なぜGitHubが優秀なのか

「保管庫」だと思っている限り、価値の8割を捨てている

GitHubを「コードのGoogle Drive」と説明されることが多いですが、それだとなぜ全世界の開発がこれ一択なのかが説明できません。優秀な理由は3つあり、3つ目が本命です。

理由1：過去が絶対に消えない

Gitは変更を「差分の連鎖」として記録します。誰が・いつ・どこを・なぜ変えたかが全部残り、3日前の状態に1秒で戻れます。Wordの変更履歴と違って、戻すのが例外処理ではなく通常操作です。

これが効くのは事故のときだけではありません。「壊しても戻せる」と分かっているから、AIに大胆な変更をやらせられます。GitHubを使っていない状態でAIに開発をさせるのは、セーブ機能のないゲームを攻略しているのと同じです。今のHarboRはZIPで手動セーブしています。

理由2：同時に複数の作業ができる

ブランチ（枝）という仕組みで、本線を壊さずに並行して試せます。AI時代にこれが決定的になったのは、エージェントを2体以上同時に走らせられるかがブランチの有無で決まるからです。Claudeに機能Aを、Codexに機能Bを、同時に別の枝で作らせる。これはZIPでは絶対にできません。

理由3（本命）：あらゆる自動化の引き金になる

GitHubは「pushされた」「PRが立った」「毎朝9時になった」といった出来事を、外部に通知できます。この通知にぶら下がる形で、他の全ツールが動きます。

用語だけ最小限

会話に必要なのはこれだけです。実際の操作はClaudeがやるので、覚える必要があるのはPRとマージの2つだけ。あなたの役割は「稟議を承認する人」です。

3. 他のツールはなぜ優秀か

Vercel：pushした瞬間に世界に公開される

Vercelは「Webサイトを見られる状態にする」担当です。優秀な理由は速さや機能ではなく、次の3つです。

• Git連携で自動デプロイ。公式に「pushされたものは既定で全部デプロイする」と明記されています。人がボタンを押す工程が構造的に消えます。
• PRごとにプレビューURLが自動発行される。本番を触らずに「これでいいですか」を関係者に見せられる。社内確認のスピードが変わるのはここです。
• 即時ロールバック。壊れたら過去の本番に戻せる。だから思い切って触れます。

Supabase：アプリの裏側の台帳

スプレッドシートとの使い分けは1行で済みます。

判断基準：人がExcel的に眺めて終わりならシート。アプリやサイトから読み書きするならSupabase。HarboRの在庫やランキングは「人も見るしアプリも読む」なので、シートを正本にしてSupabaseに写す構成が現実的です。

安定性のはしご：同じことができる手段は4段階ある

これは料金より重要な話です。「外部サービスからデータを取る」を実現する手段は複数ありますが、壊れにくさが段違いです。

4. 料金

有料になる境界線は、実は3種類しかない

サービスごとに料金表を覚える必要はありません。無料が終わる理由は3つに分類できます。

主要サービスの料金（2026年8月11日時点・公式サイト確認）

AIツールの料金

CodexのCLI版・エディタ版・クラウド版はすべて同じ使用量の枠を共有します。別課金ではありません。Claudeも同様に、Cowork・Claude Code・Webが同じ枠です。

未確認：GitHub Team/Enterpriseの13か月目以降の価格、Netlify無料プランの商用利用可否。両社とも「1か月にどれだけ使えるか」の正確な量は非公開で、5時間ごとの枠と週次上限の二重制限になっています。

5. Xserver

結論：社内ツールの置き場としては噛み合っていない

厳しい言い方になりますが、事実だけ整理します。Xserverの共用レンタルサーバーはPHPで作られたサイト（WordPressなど）を置くための設備です。今のHarboRが作っている類のツールは、これとは別の技術で動いています。

Next.jsのようなモダンなアプリは置けるのか

サーバー側で動く形（SSR）は不可。静的に書き出した形（output: 'export'）なら可能です。ただしその場合もビルド作業はXserver上ではできないので、手元かGitHub Actions側でビルドしてから転送する必要があります。手間は増えます。

取れる選択肢は3つ

1. そのまま静的サイト置き場として使い続けるコーポレートサイトやLPなど、動きのないページはXserverで問題ありません。契約を無駄にしたくないなら、この用途に寄せる。ただし自動デプロイは付いてきません。
2. 社内ツールだけをCloudflareかVercelに移す最も推奨。GitHubに置いてCloudflare Pagesに繋げば、pushした瞬間に更新される状態が無料で手に入ります。Xserverはサイトとメール用に残す。これが一番安く、一番手間が減ります。
3. Xserver VPSに上げる同じXserverでも、VPSならroot権限があるのでNode.jsもDockerも動き、常駐プロセスも立てられます。月1,700〜2,200円。ただしサーバーの管理を自分たちで背負うことになるので、非エンジニア中心の組織には向きません。

6. Mac mini

結論：今のHarboRには不要。ただし理由を知っておく価値はある

Mac miniを買うと解決するのは「自動処理の実行費用」と「iOSアプリのビルド」であって、「AIが24時間勝手に開発してくれる状態」ではありません。ここを混同すると15万円が無駄になります。

Mac miniで実現できること：セルフホストランナー

GitHub Actionsの自動処理は、通常GitHubのサーバーで実行されます（無料枠2,000分/月）。これを自社のMac miniで実行する設定にできます。これをセルフホストランナーと呼びます。

• メリット：実行そのものは無料（電気代のみ）、実行時間の上限が5日まで伸びる、社内データを外に出さずに処理できる
• デメリット：GitHub公式が「非公開リポジトリでのみ使うことを推奨」と明記しています。公開リポジトリで使うと、外部から送られたコードが自社マシン上で実行される危険があるためです。加えてOSやツールの更新、故障対応を自分たちで背負います

買う価値があるかの判定

Mac miniを買っても解決しないこと

これは重要なので明記します。「AIが勝手に判断して完成品を出してくる」状態にはなりません。issueからPRまでは自動化できますが、レビューとマージの判断、OSやツールの更新、障害対応は人間に残ります。Mac miniは人手を減らす装置ではなく、実行費用を下げる装置です。

7. 24時間開発が回る状態

3段階ある。1段目と2段目は今日からできる

1段目：デプロイを押さなくなる

GitHubとVercel（またはCloudflare）を繋ぐだけです。Vercelの公式機能名はGit Integrationで、公式ドキュメントに「pushされたものは既定で全部デプロイする」と明記されています。設定はアカウント連携してリポジトリを選ぶだけ。所要時間は10分程度で、これで手作業が3工程消えます。

おまけで付いてくる価値が大きいのがプレビューURLです。PRを立てると自動で固有のURLが発行され、PRにコメントされます。本番を触らずに「これでいいですか」を見せられるので、社内確認の往復が激減します。

2段目：あなたのPCが閉じていても走る

ここが今のHarboRの弱点です。ブラウザ操作に依存した自動タスクは、拡張機能が切れると静かに0件になります。PCに依存しない選択肢は、2026年8月時点で以下が実在します。

3段目：課題を拾って自分で直す

issueを立てると、AIが実装してPRを出してくるところまでは実在します。ただし実用範囲は「正解が機械的に判定できる狭い作業」に限られます。

参考として、GitHubは2026年5月に「コードレビューの5件に1件以上がエージェント関与」と発表しています。一方であるプロジェクトの管理者は「AIが出したPRのうち妥当なものは10本に1本で、レビュー負荷はAI導入前より増えた」と証言しています。評価は割れています。「AIがPRを出す」ことと「そのPRをマージできる」ことの間には、まだ相当な距離があります。

HarboRが今週やるなら、この順番

1. 社内ツール1つをGitHubリポジトリにする全部やらない。まず1つ。ランキング表示あたりが向いています。Claudeに「このフォルダをGitHubリポジトリにして」と頼めば完結します。
2. そのリポジトリをCloudflare PagesかVercelに繋ぐこれで「デプロイをお願いします」という依頼が消えます。ここまでで所要1時間、費用0円。
3. 壊れやすい自動タスクをAPI経由に付け替えるブラウザ操作に依存しているものを、コネクタかAPIに寄せる。同時に「失敗したらSlackに通知」を必ず入れる。黙って死ぬのを止めるのが目的です。
4. 出力先を全部Slackに統一する今チャット内に出ているだけのものを、人が必ず通る場所に出す。ここが最も費用対効果が高い。
5. それでも足りなければ3段目を試すテスト追加やライブラリ更新など、失敗しても被害のない作業から。最初から本番機能を任せないこと。

8. Claudeの仕組み

「ループ」の正体は、これだけ

AIエージェントという言葉の中身は、実質この4ステップの繰り返しです。難しいことは何もありません。

ここから導かれる、いちばん実用的な結論

指示に「確認する手段」を1行足すだけで、出力の質が変わります。

具体的には、依頼の末尾にこれを付けるだけです。「作ったら実際に実行して、エラーが出たら直してから報告して」／「計算はコードを書いて検算して」／「完成したら別のエージェントにレビューさせて」

会話が長いとバカになるのは本当か

本当です。仕組みを知ると納得できます。

• トークン：文章を細かく刻んだ単位。日本語なら1文字が1〜1.5トークン程度
• コンテキストウィンドウ：Claudeが一度に見ていられる量の上限

会話が長くなると、古い部分の解像度が落ちます。人間が長い会議の冒頭を忘れるのと同じです。だから守るべきルールは1つ。1つのチャットに1つの目的。目的が変わったら新しいチャットにする。

HarboRにはharbor-handoffというスキルがすでにあり、これを担当しています。ただ実際の使われ方を見ると「容量が限界になってから」使われています。本来は着手時に「今日はここまで」と区切りを決めて使うものです。破綻してから引き継ぎ資料を作るのは、毎回コストが発生します。

コンテキストエンジニアリング

「プロンプトの書き方を工夫する」の次に来た考え方で、Claudeの視界に、必要な情報だけを、必要なタイミングで置く技術を指します。2026年時点で「AIを使いこなす」の実質的な中身はこれです。やることは地味です。

• 必要なファイルは最初に添付する（後から貼り直させない。実際にHarboRでは契約書の取り違えで1往復無駄になったことがあります）
• 不要な情報は入れない（ノイズは判断を鈍らせる）
• 常時必要なルールはCLAUDE.mdに、時々必要な手順はSkillに置く
• 長い作業は区切って引き継ぐ

モデルの使い分け

2026年8月時点の最新はClaude Opus 5／Sonnet 5／Fable 5／Haiku 4.5です。

「毎朝メールを仕分ける」ような作業にOpusを使うのは、軽トラで済む荷物にトラックを呼ぶのと同じです。逆に契約書レビューをHaikuでやるのは危険です。使用量の枠を無駄に食っている感覚があるなら、ここを見直すと効きます。

9. 指示をどこに置くか

同じ内容でも、置き場所で効き方がまったく違う

ここがHarboRの伸びしろです。すでにCLAUDE.mdとSkillは上手く使えているので、次はフックとサブエージェントです。

フックにすべきものが、今は指示として書かれている

実例があります。「大東お問い合わせNo自動記載」の作業で、接続していたブラウザが別のショップにログインしていたため、目的の注文が「権限がありません」になり、原因判明まで多数の操作を消費しました。

これは「アカウントを確認してから始めて」とSkillに書いても、確率的に飛ばされます。フックにすれば構造的に消えます。同様に「本番のスプレッドシートに書き込む前に必ず確認を挟む」もフック向きです。

判断の階段：頻度で決める

指示の書き方：完了条件を先に書く

Claudeの最大の失敗は「間違った前提のまま全力で走ること」です。防ぎ方は2つだけです。

もう1つ。説明で伝えようとせず、現物を渡してください。スクショ、実ファイル、エラーメッセージ全文、参考サイトのURL。説明1000字よりスクショ1枚が正確です。

10. Codexとの立ち位置

一言でいうと

得意・不得意の傾向

注意：実測データを伴う調査は3件のみで、残りは個人の体験談か商用記事です。モデル世代が変わると結論が変わるため、半年前の記事は当てになりません。この表も「傾向」として読んでください。

併用の型：4パターン

AGENTS.md と CLAUDE.md の扱い

CodexはAGENTS.mdを読み、Claude CodeはCLAUDE.mdを読みます。「CLAUDE.mdがなければAGENTS.mdを読む」という説は誤りで、Anthropic公式が「Claude CodeはCLAUDE.mdを読み、AGENTS.mdは読まない」と明記しています。

ここを二重管理すると必ずズレます。実際に「規約をCLAUDE.mdにだけ書いた結果、Codexがそれを知らず、2つのAIが同じファイルに相反する編集をした」という失敗例が報告されています。

留意点：併用は両社にコードが渡ります（プラグイン経由のレビューは対象コードをOpenAIに送信します）。機密性の高いリポジトリでは事前に判断してください。またAnthropicの規約は第三者製品がサブスク認証を経由することを認めておらず、この領域のルールは2026年中に何度も変わっています。

11. HarboRの現状診断

過去セッション12本を実際に読んだ結果

先に評価すべき点を書きます。Skillの設計、CLAUDE.mdでの保存先ルール、スケジュール化の発想は、平均的な企業より2〜3段階先に行っています。以下は「そこから先」の話です。

自動タスクの健康診断

これは「増やしすぎた失敗」ではありません。主因は出力先をSlackにしていないことと失敗通知がないことの2点だけなので、直すのは軽い作業です。

最大の非効率：コードをZIPと手コマンドで運んでいる

「こんちゃんBASE分析」系のセッションでは作業フォルダ全体を1つのJSONに固めて出力し、次のセッションではZIPを解凍してgit pushするコマンドをあなたがターミナルに貼っていました。「産直売上分析」の最後は「デプロイとGitHubバックアップをお願いします」で人の作業に落ちています。「スポマネRPA」では.commandをダブルクリックしてrootパスワードを入力し、端末の出力をチャットに貼り戻していました。

その他の指摘

12. よくある疑問

たぶんこの辺が気になっているはずです

13. ロードマップ

30日でやること

判断に迷ったときの早見表

14. 用語辞典

検索して引けます