コンテンツにスキップ
トピック

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

AIを使ったアプリ開発・コード生成・デバッグ・テスト自動化の実践テクニック。初心者から中級者まで役立つガイド。

124 件の記事

並び替えで記事を探せます

AI開発・プログラミング の記事一覧

API Error: The response stopped arrivingの意味と対処——Claude Codeで応答のデータが途中で止まったとき

API Error: The response stopped arrivingの意味と対処——Claude Codeで応答のデータが途中で止まったとき

Claude Codeで応答の途中に「API Error: The response stopped arriving. The response above may be incomplete.」と出たら、接続は開いたままデータが届かなくなり、Claude Codeの監視タイマーが打ち切った状態です。完了した出力は残っているので、作業の状態を確かめてからcontinueと返せば続きから再開できます。この表示は、v2.1.227より前に「Response stalled mid-stream」と表示されていたものの改名版です。公式エラーリファレンスとネットワーク設定ドキュメントをもとに、Connection lost mid-response・The response stalled before a response was produced・Streaming response ended before any complete data was receivedとの違い、送り直されない理由、-pやサブエージェントでの扱い、版・経路・監視タイマーの確かめ方、報告のときに残す情報を整理しました。GitHubで開いた報告5件は、公式の説明と分けて、確定していない事例として扱います。

Login expired · Please run /loginの意味と対処——Claude Codeの保存ログインが更新できなくなったとき

Login expired · Please run /loginの意味と対処——Claude Codeの保存ログインが更新できなくなったとき

Claude Codeで「Login expired · Please run /login」と出たら、保存していたログインの自動更新が拒否され、Claude Codeが資格情報を消した状態です。以後の指示はAPIに送られず手元で止まるため、再試行ではなく/loginで入り直します。公式エラーリファレンスをもとに、Not logged in・OAuth token has expired・Your account is on holdとの違い、v2.1.206で表示が変わった経緯、/statusでの確認から入り直す手順、-pやCIでの対処、繰り返すときに見る版・キーチェーン・時計・CLAUDE_CONFIG_DIRを整理しました。GitHubの報告6件は、原因が確定していない事例として分けて紹介します。

Codexの「thread not found」対処法|履歴を消す前の確認と復旧事例

Codexの「thread not found」対処法|履歴を消す前の確認と復旧事例

Codexで履歴は読めるのに「thread not found」で送信できないとき、会話が消えたとは限りません。保存された履歴と、指示を受け付ける側の会話の違いを図解し、私たちの環境で再読み込み後に送信が戻った例を紹介。開き直し・再起動・短い確認文の順番と、直らない場合の引継ぎ・報告の方法を整理します。

Jevとは?文章を生成しない判断特化AIの用途・料金・限界

Jevとは?文章を生成しない判断特化AIの用途・料金・限界

Jevは、文章を生成する代わりに選択肢・評価値・Yes/Noの確率を返すTypeSafeのAIモデルです。Choice・Score・Noulの使い分け、confidenceの読み方、問い合わせを振り分けるAPIの書き方を解説します。型が決まっていても判断は間違えうるため、公式が公開する計算・日付・誘導文などの弱点、料金と入力制限、日本語で使う前の評価方法まで押さえて、自分の仕事に合うかを判断できます。

Claude Codeのopusplanとは?計画はOpus、実装はSonnetに自動で切り替える設定と注意点

Claude Codeのopusplanとは?計画はOpus、実装はSonnetに自動で切り替える設定と注意点

計画を立てるところだけ賢いモデルに任せ、実装は速くて安いモデルに回したい。Claude Code の opusplan は、それを自動でやるモデルの指定です。プランモードの間は Opus、それ以外は Sonnet で動き、/model opusplan か settings.json の model で使えます。ただし /model の一覧には出てこず、プランモードに入るたび・出るたびにモデルが切り替わるので、そのたびに会話全体をキャッシュなしで読み直します。この記事では、2026年9月15日時点の公式ドキュメント、変更履歴、GitHub の issue をもとに、設定のしかた(版の固定や 1M 文脈を含む)、プランモードから承認して実装に移る流れ、v2.0.0 で選択画面から外された経緯と Anthropic の担当者の説明、切り替えで生じるキャッシュの費用の試算とその抑え方、advisor ツールやサブエージェントとの違い、向いている使い方と向いていない使い方をまとめます。

Claude Codeのサブエージェントを別モデルで動かす方法——Sonnet・Haikuに任せる設定と実測

Claude Codeのサブエージェントを別モデルで動かす方法——Sonnet・Haikuに任せる設定と実測

Claude Code の本体は Opus 5 のまま、翻訳や大量の確認のような仕事だけを Sonnet や Haiku のサブエージェントに任せられるのか。結論はできます。サブエージェントのモデルは、呼び出すときの指定、定義ファイルの model、環境変数 CLAUDE_CODE_SUBAGENT_MODEL、本体のモデルの順に決まり、工数(effort)もサブエージェントごとに指定できます。この記事では、2026年9月15日時点の公式ドキュメントから、順番の版ごとの違い、全部を1つのモデルに固定する CLAUDE_CODE_SUBAGENT_MODEL_FORCE、接続先で変わるエイリアスの行き先、組み込みの Explore が v2.1.198 から本体のモデルを引き継ぐようになった点を整理します。そのうえで、実際に別のモデルで起動して会話ログで確かめた結果を載せます。指定どおりのモデルで動いたこと、起動するだけで数万トークンを読み込み、サブスクリプションでもサブエージェントのキャッシュは5分で切れること、そして同じ翻訳を Opus 5・Sonnet 5・Haiku 4.5 に2回ずつ任せたときの時間・料金・訳の出来の違いです。最後に、料金と使用量への効き方と、どの仕事を下げるかの判断材料をまとめます。

Claude Codeの使用量をセッション別に見る方法——どのセッションがプランを食っているか

Claude Codeの使用量をセッション別に見る方法——どのセッションがプランを食っているか

複数のセッションを並行して走らせていると、どれが週の上限を食っているのかが気になります。ところが Claude Code の /usage が出すのは、今のセッションの数字と、プラン全体の消費をスキル・サブエージェント・プラグイン・MCPサーバー別に分けた割合までで、「どのセッションが何割使ったか」は、デスクトップアプリの使用量リングにも claude.ai の設定画面にも出ません(2026年9月時点)。答えは手元に残っている会話ログ(~/.claude/projects の JSONL)にありますが、そのまま足すと数え間違えます。1回の応答が中身のかたまりごとに複数行へ書かれ、サブエージェントの記録は別のファイルにあるからです。筆者の環境で実測すると、素朴な合計は正しい値の約2倍になり、しかも誤差の倍率がセッションごとに違うため順位まで入れ替わりました。この記事では、公式の画面で見られるもの・見られないものの整理、ログの正しい数え方と約50行の集計スクリプト、1つのセッションが3割を占めていた実測結果、数字の読み方の限界、そして継続的に見たい場合の OpenTelemetry の設定までをまとめます。

Claude Codeのコンテキストは何に食われているのか——測り方と、削る順番

Claude Codeのコンテキストは何に食われているのか——測り方と、削る順番

「スキルを入れすぎるとコンテキストを圧迫する」——半分は正しく、半分は間違いです。Claude Code の公式ドキュメントによれば、スキル一覧が使うのはモデルの文脈窓の1%という決まった予算で、いくらスキルを増やしてもそこで頭打ちになります。膨らまないかわりに起きるのは「呼ばれなくなる」こと——予算からあふれると、Claude Code は呼び出し回数の少ないスキルから説明文を落とし、名前だけを残します。説明を失ったスキルは依頼と結び付かなくなりますが、エラーは出ず、遅くもなりません。この記事では、3つの計測手段(/context・/usage・/skill-doctor)の役割の違い、キャッシュミスが「5%かつ2,000トークン」で定義されること、キャッシュの寿命が契約形態で1時間から5分へ変わること、MCPのツール定義が既定で遅延読み込みになった今もCLIのほうが軽い理由、CLAUDE.mdを200行以下に保つ根拠、そして測ったあとに何から削るかを、すべて公式ドキュメントで確認できた範囲だけで整理します。

The model returned no contentの原因と対処——Claudeのエラー文言は「誰が書いたか」で意味が変わる

The model returned no contentの原因と対処——Claudeのエラー文言は「誰が書いたか」で意味が変わる

Claudeを使っていて手が止まり、出た文言をそのまま検索しても何も出てこない——そういう文字列がある。The model returned no content because the response was blocked by content filtering/The response was blocked by the provider's content filter/Streaming response ended before any complete data was received/Could not locate the Claude CLI on PATH/Connection to Claude's response was lost. Claude may still be working の5つがその例だ。共通しているのは「Claudeを使っていて出たのに、Claudeの資料を探しても見つからない(ように見える)」点で、理由は単純——いま画面に出ている文言を書いたのが、思っているプログラムとは限らないからである。本記事は個別の原因を一から解説するのではなく、その文言を書いたのは誰かを特定し、正しい記事へ振り分けるための入口として書いた。まず文言を書きうる層を4つに分ける(モデル提供元のバックエンド/Claude Code本体/起動元のIDE拡張やラッパー/第三者クライアント)。そのうえで実際に照合すると、5つのうち2つはClaude Code公式のエラーリファレンスに項目として存在していた。Streaming response ended… の公式の定義は「ヘッダは返ったがボディにClaude APIのメッセージが無い」であり、途中で切れた話ではない。Could not locate the Claude CLI on PATH は公式が「Wrapper and IDE errors=起動元のプログラムが印字するもの」として独立の章に置いている。一方でcontent filter系の2つは第三者側の語彙で、しかもOpenCodeのIssue #35736は、Vertexの404・ソケット断・本物の拒否という3つの別々の失敗がすべて同一の「blocked by content filter」として表示されると報告している。文言が正しいのは3つのうち1つだけだ。GitHubの公式ドキュメントもClaude利用時に入出力がGitHub Copilotのコンテンツフィルタを通ると明記しており、Claudeを使っていても止めたのがAnthropicのフィルタとは限らない。残る1つは公式にもRemote Controlのドキュメントにも文字列が無く、出どころを特定できなかったので名前を挙げず、自分で突き止める4手を置いた。確定・未確定はラベルで分けてある。

API Error: Connection lost mid-responseの原因と対処——v2.1.227で改名された「接続が切れた」エラー

API Error: Connection lost mid-responseの原因と対処——v2.1.227で改名された「接続が切れた」エラー

Claude Codeで応答の途中に「API Error: Connection lost mid-response. The response above may be incomplete.」と出て止まる——この文言をそのまま検索しても情報が少ないのは、これが比較的新しい名前だからだ。公式エラーリファレンスは「v2.1.227より前は Connection lost mid-response は Connection closed mid-response と表示されていた」と明記しており、同時に Response stalled mid-stream も The response stopped arriving へ、Connection closed while thinking, before producing a response も Connection lost before a response was produced へ付け替えられている。つまり中身は前からある事象で、単語だけが替わった。本記事はこの改名を起点に、公式ドキュメントと公開Issueだけを根拠として整理する。まず「途中で切れた」6つのメッセージ(Server error/Connection lost/computer went to sleep/The response stopped arriving/Part of the response never arrived/The response stream was malformed)の公式定義と、途中まで流れた出力が意図的に保持される理由——送り直すと同じツール呼び出しを二重に実行しうるため——そして復帰手順が continue と返すことである点。次に、なぜ自動で再試行されないのかを公式の Automatic retries の分岐で説明する(何も完了していない段階の切断は最大10回のバックオフで再送、思考後・出力前なら最大2回で Connection lost before a response was produced、ブロック完了後は再送せず注記を出す)。さらに切断が起きうる3つの層(手元の端末と回線/プロキシ・ゲートウェイなどの経路/サーバ側と接続の再利用)、mTLS証明書ローテーション時の再読み込み(v2.1.232以降)、9手の切り分けチェックリスト、4つのストリーム監視タイマーの既定値(first-byte 180秒/event 300秒/byte 180秒/body idle 5分)と CLAUDE_CODE_MAX_RETRIES・CLAUDE_CODE_RETRY_WATCHDOG・API_TIMEOUT_MS などの環境変数、似たメッセージ8種との見分け方の対応表、そして生のHTTPSは健全なのにCLIだけECONNRESETで落ちる実報告(#86473/#85979)を扱う。最後に、症状と復帰手順は公式に文書化されている一方で原因の公式説明はまだ無いこと、CHANGELOGに改名の記載が見当たらないことまで、確度を分けて示す。

Claude Fable 5.1の破壊的変更3つ——移行前に直す場所と、キャッシュ4分の1の意味

Claude Fable 5.1の破壊的変更3つ——移行前に直す場所と、キャッシュ4分の1の意味

Claude Fable 5.1 の移行は、モデルIDを差し替えて終わりではない。公式が「3つは破壊的変更」と明記しており、しかもそのうち2つはエラーが出る場所と原因が離れている。①強制ツール呼び出しが400になる——tool_choice の any と tool が invalid_request_error を返す。思考が常時ONのモデルで強制すると思考が飛ばされ、引数の質が落ちるためだ。②思考ブロックがモデルに紐づく——前世代からFable 5.1へ移る会話は推論を保てるが、逆向きは失われる。しかも既定では読めないブロックがモデルに届く前に破棄され、input_tokens に数えられず課金にも出ない。ルーターやフォールバックでモデルを切り替える作りでは、動いているように見えて推論だけが抜け落ちる。気づくには thinking-binding-controls-2026-08-01 ベータヘッダが要る。③過去のターンを編集すると、それ以降の思考ブロックが無効になる。system プロンプトや tools の作り直し、リマインダーを差し込んで消す書き方が該当する。この検査は2026年8月31日以降に作成されたアカウントで強制されるため、新しい検証環境では落ちるのに本番では落ちない、という食い違いが起きうる。位置づけの誤解も避けたい——Fable 5.1 はフラグシップの交代ではなく、公開時点の公式は「ほとんどの用途はOpus 5から」と明記していた。値上げはなく、変わったのはキャッシュ読み取りだけで、基本入力の0.1倍から0.025倍へ下がった。効果は同じ前置きを何度読み直すかで決まり、公式は典型的な負荷で約25%減、エージェント色の強い作業で最大約45%減としている。さらにコードを変えなくても挙動が7つ変わる(並列ツール呼び出しが減る、進捗の発話が減る、low effortで記憶から答えがち、散文が密になる、整形が減る、要約で引用を明示しない、小さな修正でも全文を書き直す)。追加機能5つ(うちキャッシュ値下げは第5章で独立して扱う)と移行手順5点まで、すべてAnthropic公式ドキュメントに基づいて整理する。

ローカルLLMでコーディングする——Ollama+Cline/Continueで、どこまでできるか

ローカルLLMでコーディングする——Ollama+Cline/Continueで、どこまでできるか

自分のPCで動かすモデルにコードを書かせる——それ自体は前からできたが、できたのは「書きかけの行の続きを埋める」補完までだった。リポジトリを読んで複数ファイルを直しテストを走らせるエージェント型は、ローカルには重すぎた。そこが2025年末から2026年にかけて動いた。Qwenの公式モデルカードには「Qwen CodeやCLINEといったほとんどのプラットフォームをサポートし、専用に設計されたfunction call形式を備える」とエディタ拡張が名指しで書かれ、Mistralも2025年12月9日にエージェント型コーディング専用のDevstral 2を発表、小さいDevstral Small 2(24B)をApache 2.0で公開した。本記事は一次情報だけで「いまどこまでできて、どこで詰まるか」を整理する。最大の関門はOllamaの既定コンテキスト長で、これは固定値ではなくVRAM量で決まる——24GiB未満なら4k、24〜48GiBで32k、48GiB以上で256k。一般的なゲーミングPCは4kに落ち、エージェントはシステムプロンプトとファイル内容とツール往復で軽く超えるため、会話の頭から静かに切り落とされる。エラーは出ないので「モデルが馬鹿」に見えるが、原因は入り口で文脈が捨てられていることだ。Ollama公式はコーディングツール用途に「少なくとも64000トークン」を明記し、伸ばした後はollama psでGPUに載っているか確認せよと案内している。モデル選定は公式発表のみで比較する——Qwen3.6-35B-A3B(活性3B・262,144コンテキスト・Apache 2.0・SWE-bench Verified 73.4)とDevstral Small 2(24B・256K・Apache 2.0・68.0%)。ContinueとClineの設計差(役割ごとに別モデルを割り当てる補完型と、自律エージェント)、そして「クラウドの何%」という比較がもはや成立しない理由——AnthropicのOpus 5発表にはSWE-bench Verifiedの数値が無く、フロンティア側はこの指標から離れつつある——まで扱う。