AI開発・プログラミング入門｜コード生成からアプリ構築まで

AIが「コードを書く手」を持った今、一人でもプロダクトを作って世に出せる時代になった。だが情報が工程ごとにバラバラで、何から手をつければいいか迷子になりがち。本記事はアイデア→設計→実装→公開→収益化までの全体地図（ロードマップ）で、個人開発を「決める→作る準備→作る→出す→育てる」の5フェーズに整理し、各工程で何をするか・どのツールを使うかを示して、深掘りが必要な工程は個別ガイドへ送る母艦（ハブ）記事。しかもコードをほぼ書かない🌱入門ルートと、AIエディタでコードを書く🔧実践ルートの2レーンで案内するので、自分に合う方をたどれば遠回りせずに動くものまでたどり着ける。仕様駆動・AIアプリビルダー・Claude Code/Cursor・AI機能の組み込み（API/RAG/ゲートウェイ）・デプロイ・SEO/AEO集客・収益化・コスト管理・一人開発×AIのつまずき5つまでを、既存の実践ガイドへの導線付きで一枚にまとめた。

Claude Codeで週次上限に当たったのに、1週間たたずに枠が全回復した——しかも何度も。ネットには「週次は実は72時間ごとにリセットされる」という裏仕様の解説まで出回っている。本当か。本記事はその正体を一次情報まで遡って検証する。ただしClaude Codeのリセット内部仕様はAnthropicが公式に明文化しておらず、上限自体も頻繁に改定されている。そこで「公式で確認できる事実」「複数の利用者が再現的に観測しているが公式回答がない事象」「単一ソースで未確認の憶測」を明確にラベル分けして扱う。結論の骨子は、早期の全回復は多くの場合Anthropicの不定期な「全体一斉リセット」（@ClaudeDevs公式が複数回告知）が主因であり、加えて「リセットまで」の表示自体が前後にズレるという再現報告があること、そして出回る「72時間周期」説は単一観測・未再現・別観測（24時間）と矛盾するため事実として鵜呑みにできないこと。断定できない部分は断定できないと明記する、2026年7月時点の検証記事。

OpenAIで実装し、次にClaudeやGeminiも試したくなった途端、プロバイダごとに違うSDK・形式・エラー処理の書き分けに時間が溶ける——そんな開発者向け。LLMゲートウェイ（AI Gateway／LLMプロキシ）は、アプリと各プロバイダの間に1枚かませる中継役で、1本のOpenAI互換APIで全モデルを叩けるようにし、フォールバック・コスト集計・仮想キー・キャッシュ・レート制限・観測といった横断的な面倒ごとを肩代わりする。本記事では、なぜ要るのか、ゲートウェイの正体、3つのタイプ（①セルフホスト型プロキシ=LiteLLM／②ホスト型=OpenRouter／③SDK型=Vercel AI SDK）の違い、LiteLLM・OpenRouter・Vercel AI SDKを軸にした選び方、接続先を差し替えるだけの最小構成コード、そして1ホップ分の遅延・ゲートウェイ自身の障害点・手数料（OpenRouterは購入額の5.5%）・機能の目減り・プライバシーという限界まで、実装目線で整理する。

AIエージェントを作ったあと必ずぶつかるのが「で、これはちゃんと動いているのか？」。プロンプトやモデルを変えた結果を感覚でなくデータで判断する仕組みがEvals（評価）だ。LLMは同じ入力でも確率的に出力が変わり、完全一致の単体テストが効きにくい。本記事は実際に作って回す手順に軸を置き、品質を測る5つの方法（①正解データセット照合 ②ルールベース判定 ③LLM-as-judge＝AIに採点させる ④回帰テスト＝変更前後の比較 ⑤本番モニタリング）、エージェント特有の評価（タスク成功率・ツール呼び出しの正しさ・軌跡・コスト）、20件から小さく始める手順、よくある落とし穴、主要ツール（Anthropic Console/Evals・OpenAI Evals・LangSmith・Langfuse・Ragas）までを実務者向けに整理する。

業務自動化で必ず出るのが「AIエージェントとRPA、どっちを使う？」。結論は二者択一ではなく役割で使い分け、2026年の勝ちパターンは両者のハイブリッド。RPAは決まった手順を高速・正確にこなす決定的な「手」（変化に弱く画面変更で壊れる）、AIエージェントは状況を読んで判断する確率的な「頭」（曖昧さ・例外に強いが毎回同じ結果とは限らない）。本記事は動作原理の違い、比較表（再現性と変化耐性のトレードオフ）、使い分け（判断軸は「規則で書き切れるか」＝書けるならRPA、書けない判断が要るならAIエージェント）、2026年の潮流（UiPath・Automation Anywhere・Blue PrismなどRPA大手のエージェント化＝収束、対立でなく「判断をどこに置くか」＝オーケストレーション優先）、そして実務の正解＝ハイブリッド（頭＝AIエージェントが判断・オーケストレーション、手＝RPAが定型実行、決定性が要る所にエージェントを置かない、ガードレールと人間承認）まで整理。各社公式情報に基づき、FAQ付きで実務者向けに解説する。

Claude Fable 5とClaude Opus 5はどちらも上位モデルだが、「常にFable 5」でも「常にOpus 5」でもなく、タスクで使い分けるのが正解。そして2026年7月24日のOpus 5登場で、この使い分けの答えは大きく動いた。前世代のOpus 4.8は「Fable 5に一段劣るが半額」だったが、Opus 5は価格を入力$5/出力$25に据え置いたまま、エージェント系ベンチマークでFable 5に並ぶか上回る（Frontier-Bench 43.3% vs 33.7%、OSWorld 2.0 70.6% vs 66.1%＝いずれも報道ベース／CursorBench 3.2は公式が「Fable 5の最高スコアと0.5%以内・コストは約半分」と明記）。一方で最難関の一発推論はFable 5がわずかに上（Humanity's Last Exam 56.5% vs 56.3%、DeepSWE v1.1 69.7% vs 68.8%＝報道ベース）。仕様はコンテキスト窓1M・最大出力128Kが同じで、fast mode（約2.5倍速）はOpus 5のみだが単価2倍かつClaude API限定、知識カットオフはOpus 5が2026年5月と新しい。判断フローは「まずOpus 5で試し、明確に頭打ちになる最難関・長時間の研究タスクだけFable 5」。実務では「Opus 5を軸に難所だけFable 5」の併用が最適で、安全ブロック時の自動振替やAPI側のフォールバック"default"モードも押さえる。可用性（6月停止→7月再展開の経緯）と単一モデル依存の回避、effort調整によるコスト最適化、FAQまで、Fable 5クラスタ（リリース/コーディング/停止/復活）とOpus 5リリース解説を結ぶ実務ガイド。

AIエージェントを業務に組み込む最初の関門が「どのフレームワークで作るか」。本記事は開発者・技術選定者の視点で、LangGraph・CrewAI・AutoGen(2026年4月GAのMicrosoft Agent Frameworkへ統合)・OpenAI Agents SDK・Google ADK・Claude Agent SDKの6つを、オーケストレーション方式(有向グラフ/役割crew/会話GroupChat/ハンドオフ/階層ツリー/自律ツールループ)・対応言語・学習曲線・制御性・本番成熟度・トークンコスト・向く用途で具体的に比較する。最大の注意点は「試作で最速のCrewAIが、本番ではトークン約3倍(あるベンチで41k vs LangGraph 18.5k)かつ非決定的で金融・医療に不向き」という、試作の勝者と本番の勝者が逆転する罠。さらに2026年はMCP(ツール連携)とA2A(エージェント間連携)で異なるフレームワークが相互運用できるようになり、ロックインが薄れた点を解説。用途別の選び方とFAQ付き。

ローカルLLMを動かす定番ツールOllama（オラマ）の使い方を、インストールからAPI活用まで初心者向けに一気通貫で解説する2026年版ガイド。本記事は、Ollamaとは何か（ローカルLLMを手軽に動かす無料OSS＝「LLM版Docker」。モデルDL・量子化形式・GPU設定を肩代わりし、ローカルにAPIサーバーも立つ。LM Studioとの違い＝Ollama=CLI/API/開発者向け、LM Studio=GUI/入門向け）、インストール（公式ollama.comからWin/Mac/Linux・Win/Macはアプリ起動でAPI自動起動・Linuxは1行スクリプト/Dockerイメージ）、基本コマンド早見（run/pull/list(ls)/ps/rm/serve、終了は/bye）、モデルの入れ方・選び方（名前+サイズタグ llama3.2:3b・VRAMに乗るサイズを選ぶ・gemma3:4b/qwen3/qwen3-coderの例・選び方は152、必要VRAMは151へ）、GUI（Open WebUIでChatGPT風画面・最初からGUIならLM Studio）、API活用（localhost:11434・ネイティブ/api/chat・OpenAI互換/v1/chat/completionsで既存コードの接続先変更だけで流用・クラウドのフォールバック）、カスタマイズ（Modelfileで自分専用モデル・環境変数OLLAMA_HOST/OLLAMA_MODELS）、つまずき対処（遅い=VRAM不足/落ちる=RAM不足8GB-16GB目安/API繋がらない=serve・11434/モデル名違い）までを公式情報（2026年時点）に基づき解説する。

ローカルLLMのおすすめモデルを「開発元・出身国・用途・サイズ・ライセンス」で整理する2026年版の比較記事。本記事は、万能の1つはなく「サイズ(VRAM上限)×用途×出身国」の3軸で選ぶという結論、主要ファミリー一覧(開発元・国つき＝Qwen:Alibaba中国・総合力/CJK強・第一候補／Llama:Meta米国・定番・情報量／Gemma:Google米国・軽量効率／DeepSeek:中国・推論コーディング/蒸留小型／Mistral:仏Mistral AI・欧州ソブリンAI・バランス／Phi:Microsoft米国・超小型でも賢いSLM／GLM:Zhipu中国・コーディング、Falcon:UAE・Command:Cohereカナダ)、「出身国」で何が変わるか(★ローカル実行なら入力データは外=開発元の国に送信されない＝中国製でも入力は中国に送られない。効くのはライセンス・組織/政府の調達方針・得意言語の3点)、日本製ローカルLLM(フルスクラッチ系=PLaMo/CyberAgent CALM3/Sarashina/NTT tsuzumi/LLM-jp、海外+日本語強化系=ELYZA(Llamaに日本語追加学習)/Swallow/Rakuten AI)、サイズ別(〜4B/7〜14B/32B/70B+具体モデル名)、用途別(総合/コーディング/日本語/推論/軽量/長文脈)、ライセンス注意(Apache2.0/MIT寛容・Llama系/Gemmaライセンスは独自条件要確認)、選び方フローと導入(Ollama pull)までを解説。オープンモデルは更新が速いため「系統＋用途＋国」で選ぶ方針。2026年時点・最新版とライセンスは配布元で要確認。

ローカルLLMを動かすのに必要なPCスペックを、初心者向けに整理する記事。本記事は、必要スペックの9割はVRAM（GPUのメモリ）で決まること（モデルがVRAMに乗れば快適・乗らなければ激遅か動かない／AppleのM系Macは統合メモリで搭載RAMをVRAMとして使える）、量子化の基礎（FP16=1パラメータ約2バイト／Q8=約1バイト＝半分／Q4=約0.5〜0.7バイト＝約1/4で個人の定番、ざっくり計算式＝パラメータ数B×バイト数＋KVキャッシュで+10〜20%）、モデルサイズ別の必要VRAM早見表（Q4前提で7B〜8B≒6〜8GB／13〜14B≒8〜12GB／32B≒20〜24GB／70B≒40〜48GB+／100B超は128GB+）、文脈長とKVキャッシュの落とし穴（7Bで4k≒+0.3GB・32k≒+2.5GB・128k≒+10GBと長文ほど増える）、GPU・Mac別の現実と速度目安（RTX 3060=入門/4090=32B級・7Bで100tok/s超/5090=32B Q8や70B/Apple M4・M5 Max 64GBで70B可・約20〜30tok/s/CPUのみは遅い）、VRAM以外（システムRAM16〜32GB・SSD・電源冷却）、予算別おすすめ3ティア（入門8〜12GB／標準24GB／本格40〜64GB+）、動かせるモデルの見極め方（VRAM確認→サイズ×0.6+文脈→収まるか）までを2026年の情報で解説する。

自分のPCで動かすローカルLLMと、クラウド経由のClaude・ChatGPT・Geminiなどサービス型LLMの違い・性能差・選び方を整理する記事。本記事は、本質（ローカル=自前主義で自由とプライバシーを取り性能と手間を払う／クラウド=預け主義で最高性能と手軽さを取り課金と依存を払う＝優劣でなくトレードオフ）、7観点の比較表（性能/コスト/プライバシー/速度/手間/オフライン/マルチモーダル）、2026年の性能差の現在地（DeepSeek・Qwen・Llama・GLM・GemmaなどオープンモデルがSWE-Bench系で数ポイント差まで猛追、要約・翻訳・定型コードはローカルでクラウド中位=Sonnet級に近い／複雑な多段推論・長文一貫性・エージェント動作・マルチモーダル＝最難関の1〜2割はクラウド優勢、オープンは数ヶ月遅れで追う位置取り、ローカルはサイズで性能が激変）、コストの違い（クラウド=従量・少量なら割安／ローカル=初期投資後トークン無料・大量利用ほど得・中量が分岐点・隠れコストは時間）、プライバシー・データ主権（ローカルはデータが一切外に出ず規制/エアギャップ向き）、必要ハード早見（量子化前提で1Bあたり0.5〜1GB、7B=VRAM8〜12GB・32B=24GB・70B=40〜48GB以上）、向き不向き、決定ガイド（機密→品質→使用量の順、多くの人はハイブリッドが最適でクラウド停止時のフォールバックにも）までを2026年6月時点の情報で解説する。

Claude Codeでモデル名の隣に出る「工数（effort）」のスライダー＝「速い↔賢い」のつまみは、AIが応答にかける手間（思考量・ツール呼び出し・応答テキストの量）を決める設定。本記事では、工数とは何か、スライダーの6項目と表示名（APIの工数は low/medium/high/xhigh/max の5段、Claude Codeはこれに独自モードのUltracodeを足した6項目。日本語表示は 低・中・高・特大・Max・Ultracode。重要：「特大」＝xhighで最大ではなく、最大の工数は「Max」。Ultracodeは工数の段ではなく上乗せモード）、各レベルの意味と保存可否（低〜特大は保存、MaxとUltracodeはセッション限定）、モデル別の対応と自動降格（xhighはFable 5・Opus 4.8・Opus 4.7 など上位モデル限定、Opus 4.6・Sonnet 4.6はxhigh不可で指定時はhighに降格。既定はClaude Codeでhigh＝Opus 4.7のみxhigh、APIの既定は全モデルhigh）、設定方法（/effortスライダーや直接指定・/effort auto、/model、--effort、CLAUDE_CODE_EFFORT_LEVEL環境変数が最優先、settingsのeffortLevel、skill/subagentのfrontmatter）、使い分け、Ultracode徹底解説（xhighを送りつつClaudeがマルチエージェントの動的ワークフローを自動起動する2層構造、xhigh対応モデル限定・セッション限定、有効化方法と使いどころ・コスト注意）、隣接機能（ultrathink＝その回だけ深く考える、/fast＝高速モード）までを公式ドキュメントと実機UI（2026年6月時点）に基づき初心者向けに解説する。