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

AIエージェントを作ったあと必ずぶつかるのが「で、これはちゃんと動いているのか？」。プロンプトやモデルを変えた結果を感覚でなくデータで判断する仕組みがEvals（評価）だ。LLMは同じ入力でも確率的に出力が変わり、完全一致の単体テストが効きにくい。本記事はEvalsとは何か、品質を測る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月時点）に基づき初心者向けに解説する。

エージェント評価（Agent Evals）は、ツールを使い複数手を踏んで目標を達成するエージェントが本当にタスクを成し遂げられるかを体系的に測る工程。単発出力を採点するLLM評価の発展形で、対象が「1つの出力」から「一連の行動」に広がる。エージェントは計画し、ツールを呼び、状態を更新するため最終出力だけでは不十分で、Googleも「出力確認だけでは足りず行動のなぜを理解する必要がある」として最終応答と軌跡(trajectory)の2系統に分ける。測る軸は5つ=①成果（タスク成功＝「予約しました」という発言ではなくDBに予約が実在するかという最終状態で判定）②軌跡（妥当な手順・正しいツールを正しい順序で）③ツール使用の正確さ（正しいツール・正しい引数・関数名や型まで照合）④効率（手数・トークン・コスト・遅延。多くはオブザーバビリティの観測値を持ち込む実務的扱い）⑤最終応答の質（LLM-as-judge/ルーブリック）。採点者はコード（速い/安い/再現可能だが脆い）→LLM-as-judge（柔軟だが非決定的で要較正）→人間（ゴールド標準だが高コスト・可能なら避ける）を使い分ける。Anthropicは「ツール呼び出しを正しい順序で踏んだかの確認は厳しすぎて脆い。エージェントは妥当な別解を見つけるので、経路ではなく成果を採点する方がよい」と勧める一方、Google/Microsoftは軌跡一致度を正式指標に持つ。固有の難所は非決定性（pass^k）・誤差の連鎖（p^t）・報酬ハッキング（DeepMindのロボットアームが掴んだように見せかけた例）・評価セットの陳腐化や汚染。実務はAnthropic推奨で、本番の失敗から20〜50件をテストケース化→自動採点でCIに乗せ→能力evalと回帰evalを分け→早く書く。SWE-bench/τ-bench/WebArena/GAIA/OSWorld/BFCL等のベンチマークも参考になる（スコアは版で動くので鵜呑みにしない）。公式情報に基づき不確実点を明示しつつ整理する。

Claude Code hooks（フック）は、Claude Codeのライフサイクルの特定の時点で自動実行されるユーザー定義のシェルコマンドで、「必ずこうなってほしい」をLLMの判断に頼らず確定的に実現する仕組み。定番イベントはSessionStart/UserPromptSubmit/PreToolUse/PostToolUse/Notification/Stop/SubagentStop/SessionEnd/PreCompactの9つで、PreToolUse等はブロック可能（保護ファイル編集や危険コマンドを止められる）。設定はsettings.jsonの"hooks"キーにイベント名→マッチャ→type+commandの形で記述。入出力はstdinにJSON（session_id・tool_input等）を受け取り、終了コード0（成功）/2（ブロック、stderrがClaudeに渡る）または構造化JSON（continue・decision:block・permissionDecision:deny/allow/ask等）で返す。原則は「制限はきつくできるが緩くできない」（denyは常に優先、bypassPermissionsでも止まる）。定番ユースケースは編集後の自動整形（PostToolUse＋Edit|Write）・保護ファイル防御・危険コマンド阻止・コンテキスト再注入（SessionStart）・通知/監査ログ・終了前テスト（Stop）。安全面では任意のシェルコマンドを自分の権限で実行するため信頼できるフックだけを設定し、入力の検証/クォート・機微ファイル回避が必須。フック設定はセッション開始時にスナップショットとして固定され、セッション中の変更が反映されないのは安全機構。公式ドキュメントに基づき、定番9イベントと入出力契約を軸に整理する。

チェックポイント（checkpointing）と/rewindは、Claude Codeが作業中にClaudeのファイル編集を自動追跡し、数キーで「やり直す前」まで巻き戻せる安全網。スナップショットは各編集の前に自動で取られ、送った各プロンプトが復元ポイントになり、セッションをまたいで保持される。使い方は/rewindと打つか入力欄が空のときにEscを2回押してメニューを開き、一覧から地点を選んで「コードと会話を復元／会話を復元／コードを復元」を選ぶ（入力欄に文字が残っていればEsc2回は入力のクリアになる点に注意）。最重要の注意は、復元されるのはClaudeの編集ツール（Write／Edit／NotebookEdit）によるファイル変更だけで、bashコマンドの変更（rm／mv／cp）・セッション外や別セッションの変更・ディレクトリ操作・リモートファイル・DB等は巻き戻しで戻らないこと。公式は「チェックポイント＝ローカルの取り消し、Git＝恒久的な履歴」と位置づけ、補完はするが置き換えはしないと明言しており、節目ではGitコミットの併用が鉄則。さらに/rewindはツール同時実行やthinkingブロック関連の400エラーからの復旧手段でもあり、製品自身が実行を促す（ただしv2.1.156より前は/rewindでクリアできないことがあるためclaude updateが先）。対話型CLIでは既定で有効、Agent SDKはオプトイン、保持はセッションと一緒に30日（設定可）。公式ドキュメントに基づき不確実点を明示しつつ整理する。