[{"data":1,"prerenderedAt":539},["ShallowReactive",2],{"post-index":3,"post-ai-cognitive-debt-approval":453},{"posts":4,"categories":402,"tags":411},[5,17,35,43,60,74,87,105,122,144,156,167,179,193,208,223,239,250,264,275,285,296,308,319,331,343,356,367,377,387],{"slug":6,"title":7,"description":8,"publishedAt":9,"updatedAt":9,"category":10,"tags":13,"thumbnail":16},"ai-cognitive-debt-approval"," 認知負債は「承認」で生まれる ── コーディングエージェント時代の意図負債と、個人・チームの向き合い方","コーディングエージェントに実装を任せると、コードは速く書けるのに人の理解が追いつかない。認知負債・意図負債・理解負債の違いを「下り」と「上り」で整理し、負債が生まれる承認の瞬間と、個人とチームでできる対策、まだ答えのない問いを、自分の体験から考える。","2026-11-03T17:12:07.686Z",{"name":11,"slug":12},"AI","ai",[14],{"name":15,"slug":15},"organization",null,{"slug":18,"title":19,"description":20,"publishedAt":21,"updatedAt":21,"category":22,"tags":23,"thumbnail":16},"design-harness-personal-product","デザインハーネスを個人開発で組んだ — AI が作る画面のずれを止めるまで","デザイナーのいない個人開発で、AI が作る画面のずれを止めるまでの記録。Codex の Product Design で画像の案を出して画面を作り直し、デザインファイルとコードの食い違いを正本の分担で片付け、lint・見た目の比較・AI の評価役からなるデザインハーネスで外れたら止める仕組みを組んだ。","2026-11-03T15:39:02.665Z",{"name":11,"slug":12},[24,27,30,32],{"name":25,"slug":26},"claude code","claude-code",{"name":28,"slug":29},"design system","design-system",{"name":31,"slug":31},"codex",{"name":33,"slug":34},"design harnes","design-harnes",{"slug":36,"title":37,"description":38,"publishedAt":39,"updatedAt":39,"category":40,"tags":41,"thumbnail":16},"claude-code-mods-intro","Claude Codeの「Claude Mods」とは？ 入れてみた3つのmodと、安全に入れる手順","Claude Codeの新機能Claude Mods（v2.1.287〜）を紹介する。hooks・skills・MCPとの違い、入れてみたmod 3つ（prompt-rail・md-prompt・qa-guide）の使い方、claude plugin validateで中身を確かめて入れる手順をまとめた。","2026-11-03T15:30:44.678Z",{"name":11,"slug":12},[42],{"name":25,"slug":26},{"slug":44,"title":45,"description":46,"publishedAt":47,"updatedAt":47,"category":48,"tags":51,"thumbnail":16},"worktree-shared-reverse-proxy","AI 時代の並列開発の環境構築 — git worktree ごとにアプリを同時に動かす","git worktree の並列開発で、各 worktree のフロントとバックを同時に動かす Docker Compose 構成を紹介する。ポートはずらさず共有のリバースプロキシでホスト名に振り分け、DB は 1 つを共有ネットワークに置いて全 worktree から参照する。","2026-11-03T15:24:32.067Z",{"name":49,"slug":50},"Dev Env","dev-env",[52,54,57],{"name":53,"slug":53},"git",{"name":55,"slug":56},"Docker","docker",{"name":58,"slug":59},"開発環境","development-environment",{"slug":61,"title":62,"description":63,"publishedAt":64,"updatedAt":64,"category":65,"tags":66,"thumbnail":16},"ghostty-herdr-dev-env","Ghostty + herdr で組む開発環境（2026年9月版） — AI エージェントを並べてターミナルで開発する","WezTerm + tmux + 自作ツールから Ghostty + herdr に移した私の開発環境を紹介する。Claude Code・Codex・takt を並べて動かす 1 タスクの流れ、ターミナル内ブラウザで画面の要素を AI に渡す方法、Neovim・lazygit・hunk・Nix まで層ごとにまとめた。","2026-11-03T15:14:47.700Z",{"name":49,"slug":50},[67,68,70,72],{"name":58,"slug":59},{"name":69,"slug":69},"herdr",{"name":71,"slug":71},"ghostty",{"name":73,"slug":73},"terminal",{"slug":75,"title":76,"description":77,"publishedAt":78,"updatedAt":78,"category":79,"tags":80,"thumbnail":16},"dotfiles-operation-and-nix","設定ファイルを端末に置いたままにしない — dotfiles 運用のすすめと、その先の Nix","設定ファイルを Git リポジトリで管理する dotfiles 運用の始め方と、その先で効いてくる Nix の話。何を入れて何を入れないか、配線の 3 手法の比較、運用して見えてくる穴、3 端末を 1 つの設定で回すところまでを実例で書く。","2026-11-03T15:04:48.084Z",{"name":49,"slug":50},[81,82,85],{"name":58,"slug":59},{"name":83,"slug":84},"Nix","nix",{"name":86,"slug":86},"dotfiles",{"slug":88,"title":89,"description":90,"publishedAt":91,"updatedAt":91,"category":92,"tags":93,"thumbnail":102},"opencode-go-plan-evaluation","OpenCode Go プランを評価する — 月$10 で LLM オーケストレーションの中間層は作れるか","OpenCode が提供する月額固定の Go プラン（初月$5、翌月以降$10\u002F月）を、料金体系・想定ユースケース・3層 LLM 構成における中間モデル層としての適合性まで含めて評価する。","2026-05-07T12:12:31.936Z",{"name":11,"slug":12},[94,97,100],{"name":95,"slug":96},"Harness Engineering","harness-engineering",{"name":98,"slug":99},"LLM","llm",{"name":101,"slug":101},"opencode",{"url":103,"description":104},"https:\u002F\u002Fimages.ctfassets.net\u002Fd3b1looh8iwg\u002F6Nh8tVuSCuHunaVeqyegdU\u002F0fee3536b9ee406b986430ebc1b8ebfd\u002FOpenCode_Go_%C3%A3__%C3%A3__%C3%A3__%C3%A3__%C3%A3__%C3%A8__%C3%A4__%C3%A3__%C3%A3__.png","",{"slug":106,"title":107,"description":108,"publishedAt":109,"updatedAt":109,"category":110,"tags":111,"thumbnail":120},"prompt-context-harness-engineering","ハーネスエンジニアリングとは何か：プロンプト→コンテキスト→ハーネスへ至るAIエージェント設計の変遷","「ハーネスエンジニアリング」とは何か。プロンプトエンジニアリング、コンテキストエンジニアリングから続く3段階の変遷を、論文引用（Lost in the Middle \u002F SWE-bench）とClaude Codeの実装例（フック・ルール・Skill）で階層構造として整理する。","2026-04-07T13:04:49.564Z",{"name":11,"slug":12},[112,115,116,119],{"name":113,"slug":114},"Prompt Engineering","prompt-engineering",{"name":95,"slug":96},{"name":117,"slug":118},"Context Engineering","context-engineering",{"name":98,"slug":99},{"url":121,"description":104},"https:\u002F\u002Fimages.ctfassets.net\u002Fd3b1looh8iwg\u002F74HnVGS2R8wphJ1nGHgLfb\u002Fb87d3d6e35ccc518e04d9959c7637a88\u002Fã__ã__ã__ã__ã__ã__ã__ã__ã__ã__ã_ªã__ã__ã__ã__ã__ä__ã__ï__ã__ã__ã__ã__ã__ã__ã__â__ã__ã__ã__ã__ã__ã__â__ã__ã__ã__ã__ã__è__ã__A.png",{"slug":123,"title":124,"description":125,"publishedAt":126,"updatedAt":126,"category":127,"tags":130,"thumbnail":142},"authjs-v5-jwt-dual-timeout-bff-django","Auth.js v5 でJWT二重タイムアウトを実装する：BFF + Django連携の設計パターン","Auth.js v5のjwt callbackで8時間の絶対有効期限と30分のアイドルタイムアウトを両立する実装方法を解説。Next.js MiddlewareによるBFF API保護とDjango REST Frameworkとの Token Exchange パターンも紹介する。","2026-04-06T12:45:28.328Z",{"name":128,"slug":129},"Programming","programming",[131,134,136,139],{"name":132,"slug":133},"auth.js","auth-js",{"name":135,"slug":135},"jwt",{"name":137,"slug":138},"Django REST Framework","django-rest-framework",{"name":140,"slug":141},"Next.js","next-js",{"url":143,"description":104},"https:\u002F\u002Fimages.ctfassets.net\u002Fd3b1looh8iwg\u002FpqkFfHKpf2UqoNrB6KrKS\u002F672a78076f28d88b31509c230f9c3f64\u002FAuth.js_v5_ã__ã__JWTäº_é__ã__ã__ã__ã__ã__ã__ã__å__è__ã__ã__ï__BFF___Djangoé__æ_ºã__è__è__ã__ã__ã__ã__ã__.png",{"slug":145,"title":146,"description":147,"publishedAt":148,"updatedAt":148,"category":149,"tags":150,"thumbnail":154},"claude-code-spec-to-growing-claudemd","仕様書を「渡す」からCLAUDE.mdを「育てる」へ — Claude Codeの使い方が変わった話","Claude Codeに仕様書を丸ごと渡す運用から、CLAUDE.mdを継続的に育てる運用へ。「間違えたら追加」ルールの実践例と、20行→146行+31スキルに育てた記録。","2026-04-02T14:58:11.375Z",{"name":11,"slug":12},[151,152,153],{"name":25,"slug":26},{"name":113,"slug":114},{"name":117,"slug":118},{"url":155,"description":104},"https:\u002F\u002Fimages.ctfassets.net\u002Fd3b1looh8iwg\u002FqybhQ2TQSYQhIvDhWxqvs\u002F9f8b888e11a76223c8a1b1da42df5ce1\u002Fä__æ__æ__ã__ã__æ__ã__ã__ã__ã__CLAUDE.mdã__ã__è__ã__ã__ã__ã___â___Claude_Codeã__ä__ã__æ__ã__ã__å__ã__ã__ã__è__.png",{"slug":157,"title":158,"description":159,"publishedAt":160,"updatedAt":160,"category":161,"tags":162,"thumbnail":165},"claude-code-harness-engineering","Claude Codeを覚醒させる「ハーネスエンジニアリング」 CLAUDE.md・Hooks・Rules設定の徹底解説","プロンプトを書く時代から、AIが最高に働く環境を設計する時代へ。Claude CodeのCLAUDE.md、Hooks、Rules、Settings、Agent Routingを体系的に解説し、自作のオーケストレーションシステム「ai-orchestra」による統合管理の実践例を紹介する。","2026-03-22T08:59:48.575Z",{"name":11,"slug":12},[163,164],{"name":25,"slug":26},{"name":95,"slug":96},{"url":166,"description":104},"https:\u002F\u002Fimages.ctfassets.net\u002Fd3b1looh8iwg\u002F3liirUgzBlFBuAMoytyN5E\u002F66ba6b07385791bcaae4ddf404f06ce1\u002FClaude_Codeã__è__é__ã__ã__ã__ã__ã__ã__ã__ã__ã__ã__ã__ã__ã__ã__ã_ªã__ã__ã__ã___CLAUDE.mdã__Hooksã__Rulesè__å__ã__å__åº_è__èª_.png",{"slug":168,"title":169,"description":170,"publishedAt":171,"updatedAt":172,"category":173,"tags":174,"thumbnail":177},"claude-code-dev-toolchain","Claude Code開発を支える私のツールチェイン — ターミナルからAIデザインまで","Claude Code CLIを中心とした開発環境を紹介する。WezTerm + Tmuxのターミナル構成、GTRやBatonによる並列開発、ステータスライン・通知フックのカスタマイズ、MCP\u002Fプラグイン活用、Aqua VoiceやPencilとの連携まで、実際に使っているツールチェインの全体像をまとめた。","2026-03-21T19:30:43.616Z","2026-11-03T15:18:14.982Z",{"name":49,"slug":50},[175,176],{"name":25,"slug":26},{"name":58,"slug":59},{"url":178,"description":104},"https:\u002F\u002Fimages.ctfassets.net\u002Fd3b1looh8iwg\u002F4wFUBAqC9yuIgeo3xWVHJM\u002F8843248b854fee93872b5ac519d16bc2\u002FClaude_Codeé__ç_ºã__æ__ã__ã__ç__ã__ã__ã__ã__ã__ã__ã__ã___â___ã__ã__ã__ã__ã__ã__ã__AIã__ã__ã_µã__ã__ã__ã__ã__ã__.png",{"slug":180,"title":181,"description":182,"publishedAt":183,"updatedAt":184,"category":185,"tags":186,"thumbnail":191},"lazygit-commit-message-auto-generate","【コピペで導入】lazygit × Claude Code でコミットメッセージ自動生成","lazygit の customCommands と Claude Code の --print モードを組み合わせ、Ctrl+G 一発で Conventional Commits 形式のコミットメッセージを自動生成する方法を解説。コピペ可能な完成形設定と、4段階の試行錯誤で得たハマりポイントを共有します。","2026-03-15T04:36:20.532Z","2026-11-03T15:18:53.496Z",{"name":49,"slug":50},[187,188,189],{"name":53,"slug":53},{"name":25,"slug":26},{"name":190,"slug":190},"lazygit",{"url":192,"description":104},"https:\u002F\u002Fimages.ctfassets.net\u002Fd3b1looh8iwg\u002F62ov1mzeLUjRm6cbzQ7R92\u002F3bc21a7fe7ec517ad3258b6264d4097e\u002Fã__ã__ã__ã__ã__ã__ã__ã__å__å__ã__lazygit_Ã__Claude_Code_ã__ã__ã__ã__ã__ã__ã__ã__ã__ã__ã__ã__è_ªå__ç__æ__.png",{"slug":194,"title":195,"description":196,"publishedAt":197,"updatedAt":198,"category":199,"tags":200,"thumbnail":206},"git-worktree-runner-guide","git-worktree-runner で worktree 管理が劇的にラクになった話","git-worktree-runner（GTR）は git worktree の操作を 1 コマンドに集約する CLI ラッパーです。Taskfile.yaml での運用から GTR に移行した体験を元に、インストール・設定・AI 並列開発での活用法を解説します。","2026-03-09T15:32:31.316Z","2026-11-03T15:18:33.924Z",{"name":49,"slug":50},[201,202,204],{"name":53,"slug":53},{"name":203,"slug":203},"git-worktree",{"name":205,"slug":205},"git-worktree-runner",{"url":207,"description":104},"https:\u002F\u002Fimages.ctfassets.net\u002Fd3b1looh8iwg\u002F7BRBfHFocF2ABOeOQmtIic\u002Fa63ce99493098bc42123e4315f43d768\u002Fgit-worktree-runner_ã__ã___worktree_ç__ç__ã__ã__å__ç__ã__ã__ã__ã__ã_ªã__ã__è__.png",{"slug":209,"title":210,"description":211,"publishedAt":212,"updatedAt":212,"category":213,"tags":214,"thumbnail":221},"rag-basic-knowledge","RAG入門 — 検索拡張生成の基礎知識を実験結果とともに学ぶ","RAG（検索拡張生成）の仕組みをVectorDB・Embedding・チャンク分割の3要素に分解して解説。Embeddingモデル変更で正答率0\u002F5→4\u002F5に改善した検証データも公開。","2026-03-01T11:29:25.841Z",{"name":11,"slug":12},[215,218,219],{"name":216,"slug":217},"RAG","rag",{"name":98,"slug":99},{"name":220,"slug":220},"ollama",{"url":222,"description":104},"https:\u002F\u002Fimages.ctfassets.net\u002Fd3b1looh8iwg\u002F1enfpUixTuvis0oX9x5Cfa\u002F934aed76ac994412ceb37dfdf5dc6f6c\u002FRAGå__é___â___æ__ç__æ__å_µç__æ__ã__å_ºç__ç__è__ã__å__é__çµ_æ__ã__ã__ã__ã__å__ã_µã__.png",{"slug":224,"title":225,"description":226,"publishedAt":227,"updatedAt":228,"category":229,"tags":230,"thumbnail":237},"engineer-ai-daily-workflow","1人のエンジニアがAIを日常にどう組み込んでいるか — 契約サービスから活用フローまで全公開","Claude Code、ChatGPT、Gemini、Aqua Voice、Adobe Fireflyの5サービスを使い分けるエンジニアが、開発・情報収集・ブレスト・音声入力・振り返りまで、AIを日常に組み込んだリアルな活用フローを全公開します。","2026-02-18T14:13:58.531Z","2026-02-18T14:14:12.514Z",{"name":11,"slug":12},[231,232,234],{"name":98,"slug":99},{"name":233,"slug":233},"openclaw",{"name":235,"slug":236},"マルチエージェント","multi-agent",{"url":238,"description":104},"https:\u002F\u002Fimages.ctfassets.net\u002Fd3b1looh8iwg\u002F5gBC06O8WX2GX8wmoOXQfy\u002F27a11e0f280f642a781e462dead9d3ae\u002F1人ã__ã__ã__ã__ã__ã__ã__ã__ã__AIã__æ__å__ã__ã__ã__ã__çµ_ã__è__ã__ã__ã__ã__ã__ã___â___å__ç__ã_µã__ã__ã__ã__ã__ã__æ__ç__ã__ã_.png",{"slug":240,"title":241,"description":242,"publishedAt":243,"updatedAt":243,"category":244,"tags":245,"thumbnail":248},"ai-orchestra-design-and-practice","Claude Codeマルチエージェント実践｜AI Orchestraで超えた2つの壁","Claude Code単体運用で生じるコンテキスト溢れ・役割混乱の課題を、25種の専門エージェントとClaude×Codex×Geminiのマルチモデル連携で解決するオーケストレーションシステム「AI Orchestra」。その設計思想、Hookによる自動ルーティング、並列レビューなどの実装を具体的に紹介します。","2026-02-08T08:01:16.212Z",{"name":11,"slug":12},[246,247],{"name":235,"slug":236},{"name":98,"slug":99},{"url":249,"description":104},"https:\u002F\u002Fimages.ctfassets.net\u002Fd3b1looh8iwg\u002F6j2KWOOo7wJfUobTCg3o2w\u002F126c8d413cd9a56e64fba107544ec4e1\u002FClaude_Codeã__ã__ã__ã__ã__ã__ã__ã__ã__ã__å__è_µï__AI_Orchestraã__ã__è__ã__ã__2ã__ã__å__.png",{"slug":251,"title":252,"description":253,"publishedAt":254,"updatedAt":255,"category":256,"tags":257,"thumbnail":262},"ai-benchmark-guide","AIベンチマーク読み方ガイド｜SWE-bench・GPQA・ARC-AGIの意味と活用法","SWE-bench、GPQA Diamond、ARC-AGI、Terminal-Benchなど主要AIベンチマークの読み方を解説。2026年2月最新のモデルスコア比較と、コーディングエージェントへのタスク振り分けに活かす実践的な指針を紹介します。","2026-02-07T16:10:19.131Z","2026-02-07T16:11:56.095Z",{"name":11,"slug":12},[258,259],{"name":98,"slug":99},{"name":260,"slug":261},"Benchmark","benchmark",{"url":263,"description":104},"https:\u002F\u002Fimages.ctfassets.net\u002Fd3b1looh8iwg\u002F3QlfPsXmLogdj9o4mdgFYQ\u002F73a69ca272ac4e4fdcf977f322c0218a\u002FAIã__ã__ã__ã__ã__ã__ã__èª_ã__æ__ã__ã__ã__ã__ã__ï__SWE-benchã__GPQAã__ARC-AGIã__æ__å__ã__æ__ç__æ__.png",{"slug":265,"title":266,"description":267,"publishedAt":268,"updatedAt":268,"category":269,"tags":270,"thumbnail":273},"multi-agent-building-guide","マルチエージェント構築入門｜構成の全体像と3つの実装アプローチ","マルチエージェントの構築方法を解説。オーケストレーター・サブエージェント・ツール連携の3要素から、自作・フレームワーク・既存ツール活用の選択肢まで。Claude Codeでの実装例付き。","2026-02-05T12:52:58.095Z",{"name":11,"slug":12},[271,272],{"name":98,"slug":99},{"name":235,"slug":236},{"url":274,"description":104},"https:\u002F\u002Fimages.ctfassets.net\u002Fd3b1looh8iwg\u002F68XZFvLA17pegNy0lHCrYN\u002Ff90202a483bf087f4fa4cbb80dae934e\u002Fã__ã__ã__ã__ã__ã__ã__ã__ã__ã__æ__ç__å__é__ï__æ__æ__ã__å__ä__å__ã__3ã__ã__å__è__ã__ã__ã__ã__ã__ã__.png",{"slug":276,"title":277,"description":278,"publishedAt":279,"updatedAt":279,"category":280,"tags":281,"thumbnail":283},"openclaw-security-and-features","OpenClaw徹底解説 ── セルフホスト型AIアシスタントの可能性とセキュリティリスク","「AIが自分の代わりにメッセージを返信してくれたら…」そんな願いを叶えるツールが、いま爆発的な人気を集めています。その名も「OpenClaw」。わずか2ヶ月でGitHub Stars 10万を突破し、週間200万人が訪れるほどの注目を浴びています。  しかし、その急成長の裏には商標問題、詐欺騒動、そして深刻なセキュリティ脆弱性の発覚と、波乱万丈なドラマがありました。","2026-02-03T15:20:26.415Z",{"name":11,"slug":12},[282],{"name":233,"slug":233},{"url":284,"description":104},"https:\u002F\u002Fimages.ctfassets.net\u002Fd3b1looh8iwg\u002F7aKouVOZSGnzVUGgLQfa22\u002F5688eb515dc5f0b2c301b9b8c267ec20\u002F00036.png",{"slug":286,"title":287,"description":104,"publishedAt":288,"updatedAt":289,"category":290,"tags":291,"thumbnail":294},"custom-instructions","ChatGPTやClaudeがもっと賢くなる！カスタム指示の書き方と実例集","2026-01-30T17:42:57.415Z","2026-02-03T15:03:06.461Z",{"name":11,"slug":12},[292,293],{"name":98,"slug":99},{"name":113,"slug":114},{"url":295,"description":287},"https:\u002F\u002Fimages.ctfassets.net\u002Fd3b1looh8iwg\u002F4EojonTOebJGeiaXf98ol0\u002F9e391fc8bd6e548f8c96136c805b49d7\u002FChatGPTã__Claudeã__ã__ã__ã__ã__è__ã__ã_ªã__ï__ã__ã__ã__ã__æ__ç_ºã__æ__ã__æ__ã__å__ä__é__.png",{"slug":297,"title":298,"description":299,"publishedAt":300,"updatedAt":301,"category":302,"tags":303,"thumbnail":306},"ollama-local-llm-setup","ローカルLLMはまず小さめモデルから：Ollamaで始める導入〜疎通確認","acでOllamaを使い、ローカルLLMを最短で起動→1回応答まで確認する手順を解説。モデル選定の考え方、遅い\u002Fメモリ\u002Fディスクの切り分け、API疎通(curl)もまとめます。","2026-01-18T06:40:49.270Z","2026-01-21T13:05:14.924Z",{"name":11,"slug":12},[304,305],{"name":220,"slug":220},{"name":98,"slug":99},{"url":307,"description":104},"https:\u002F\u002Fimages.ctfassets.net\u002Fd3b1looh8iwg\u002F1NQmtspOD1S6LEb4SrCYIQ\u002F49c213de131a9a4ea139c32e805f3b01\u002Fã__ã__ã__ã__LLMã__ã__ã__ã__å__ã__ã__ã__ã__ã__ã__ã__ã__ï__Ollamaã__ã__å__ã__ã__å__å__ã__ç__é__ç_ºèª_.png",{"slug":309,"title":310,"description":104,"publishedAt":311,"updatedAt":312,"category":313,"tags":314,"thumbnail":317},"llm-leaderboard-score-guide","LLMリーダーボードの読み方：スコア指針とベンチマーク確認手順","2026-01-10T08:57:26.636Z","2026-01-18T06:55:58.990Z",{"name":11,"slug":12},[315,316],{"name":260,"slug":261},{"name":98,"slug":99},{"url":318,"description":104},"https:\u002F\u002Fimages.ctfassets.net\u002Fd3b1looh8iwg\u002F8u7GQ3mAlcvIHOc5bFJc6\u002Fa953bf74c33117efa393eaf8541f515a\u002FLLMã_ªã__ã__ã__ã__ã__ã__ã__ã__ã__ã__èª_ã__æ__.png",{"slug":320,"title":321,"description":104,"publishedAt":322,"updatedAt":322,"category":323,"tags":324,"thumbnail":329},"vite_docker_esbuild-error","Vite + Docker + ESBuild Errorの解決","2021-11-12T03:53:22.965Z",{"name":128,"slug":129},[325,326],{"name":55,"slug":56},{"name":327,"slug":328},"Vite","vite",{"url":330,"description":104},"https:\u002F\u002Fimages.ctfassets.net\u002Fd3b1looh8iwg\u002F5gqsl4ZChCI3uaSXQA86du\u002F3c94f9928ffaaab2d8911d32e742de1e\u002Fprogramming.jpg",{"slug":332,"title":333,"description":104,"publishedAt":334,"updatedAt":335,"category":336,"tags":337,"thumbnail":341},"nuxt-router-scroll-control","Nuxt.jsのページ遷移時のスクロール制御したい","2021-10-28T14:31:11.276Z","2021-10-28T14:35:33.155Z",{"name":128,"slug":129},[338],{"name":339,"slug":340},"Nuxt.js","nuxt-js",{"url":342,"description":104},"https:\u002F\u002Fimages.ctfassets.net\u002Fd3b1looh8iwg\u002F6dqpNPZsBJJ7x9XJj1Ld1z\u002Fcd1bb9323a8ffb0657ad79525403e1ff\u002Fnuxt.jpg",{"slug":344,"title":345,"description":104,"publishedAt":346,"updatedAt":347,"category":348,"tags":349,"thumbnail":354},"react-drf-img_uploader-backend","React × DRFで画像アップロード機能作成 (バックエンド実装編)","2021-10-26T02:56:58.215Z","2021-10-27T11:37:43.829Z",{"name":128,"slug":129},[350,353],{"name":351,"slug":352},"React","react",{"name":137,"slug":138},{"url":355,"description":104},"https:\u002F\u002Fimages.ctfassets.net\u002Fd3b1looh8iwg\u002F4jbVtK0nXsMKZplpBAwhri\u002Fb0ccef5153d92a7947eb0c682008255c\u002Fdjango-rest-framework.jpg",{"slug":357,"title":358,"description":104,"publishedAt":359,"updatedAt":360,"category":361,"tags":362,"thumbnail":365},"react-drf-img_uploader-frontend","React × DRFで画像アップロード機能作成 (フロント実装編)","2021-10-26T02:39:01.629Z","2021-10-27T11:37:24.670Z",{"name":128,"slug":129},[363,364],{"name":351,"slug":352},{"name":137,"slug":138},{"url":366,"description":104},"https:\u002F\u002Fimages.ctfassets.net\u002Fd3b1looh8iwg\u002F3uFOs5NyHOvRqYgE1lQ3p6\u002Fd79c8fabb7d4151c5773ffe1cdd2bce3\u002Freact.jpg",{"slug":368,"title":369,"description":104,"publishedAt":370,"updatedAt":371,"category":372,"tags":373,"thumbnail":376},"react-drf-img_uploader-environment","React × DRFで画像アップロード機能作成 (環境構築編)","2021-10-26T02:00:01.702Z","2021-10-27T11:47:28.398Z",{"name":128,"slug":129},[374,375],{"name":351,"slug":352},{"name":137,"slug":138},{"url":330,"description":104},{"slug":378,"title":379,"description":104,"publishedAt":380,"updatedAt":381,"category":382,"tags":383,"thumbnail":385},"docker-install-procedure","各OS毎のDockerインストール手順","2021-10-26T01:43:54.692Z","2022-02-07T14:32:07.791Z",{"name":128,"slug":129},[384],{"name":55,"slug":56},{"url":386,"description":104},"https:\u002F\u002Fimages.ctfassets.net\u002Fd3b1looh8iwg\u002F3aVlE8NIfX12QvTafaC8xE\u002Fd00bf480e212538e1816fc10d2e7b77d\u002Fdocker.jpg",{"slug":388,"title":389,"description":104,"publishedAt":390,"updatedAt":391,"category":392,"tags":395,"thumbnail":399},"notion-clear-trash","Notionのゴミ箱を一括削除する","2021-09-12T13:04:59.853Z","2021-10-21T14:29:03.528Z",{"name":393,"slug":394},"Lifestyle","lifestyle",[396],{"name":397,"slug":398},"Notion","notion",{"url":400,"description":401},"https:\u002F\u002Fimages.ctfassets.net\u002Fd3b1looh8iwg\u002F5binM4YxsZdSXX9SKkGyNP\u002Fcf39353211db8b3e0c4ac18e03b55527\u002Fnotion.jpg","Notion記事用のサムネイル",[403,405,407,409],{"name":49,"slug":50,"count":404},6,{"name":11,"slug":12,"count":406},16,{"name":128,"slug":129,"count":408},7,{"name":393,"slug":394,"count":410},1,[412,414,415,417,418,420,421,422,423,424,425,427,428,429,430,431,432,433,434,435,436,437,438,439,440,441,442,443,444,445,446,447,448,449,450],{"name":98,"slug":99,"count":413},10,{"name":25,"slug":26,"count":404},{"name":137,"slug":138,"count":416},4,{"name":58,"slug":59,"count":416},{"name":55,"slug":56,"count":419},3,{"name":53,"slug":53,"count":419},{"name":95,"slug":96,"count":419},{"name":113,"slug":114,"count":419},{"name":351,"slug":352,"count":419},{"name":235,"slug":236,"count":419},{"name":260,"slug":261,"count":426},2,{"name":117,"slug":118,"count":426},{"name":220,"slug":220,"count":426},{"name":233,"slug":233,"count":426},{"name":132,"slug":133,"count":410},{"name":31,"slug":31,"count":410},{"name":33,"slug":34,"count":410},{"name":28,"slug":29,"count":410},{"name":86,"slug":86,"count":410},{"name":71,"slug":71,"count":410},{"name":203,"slug":203,"count":410},{"name":205,"slug":205,"count":410},{"name":69,"slug":69,"count":410},{"name":135,"slug":135,"count":410},{"name":190,"slug":190,"count":410},{"name":140,"slug":141,"count":410},{"name":83,"slug":84,"count":410},{"name":397,"slug":398,"count":410},{"name":339,"slug":340,"count":410},{"name":101,"slug":101,"count":410},{"name":15,"slug":15,"count":410},{"name":216,"slug":217,"count":410},{"name":73,"slug":73,"count":410},{"name":327,"slug":328,"count":410},{"name":451,"slug":451,"count":452},"takt",0,{"slug":6,"title":7,"description":8,"publishedAt":9,"updatedAt":9,"category":454,"tags":455,"thumbnail":16,"html":457,"headings":458,"readingMinutes":512,"older":513,"newer":16,"related":520},{"name":11,"slug":12},[456],{"name":15,"slug":15},"\u003Cp>AI が「この方針で実装します」と計画を出す。私はそれを読み、承認する。実装が進む。そして後になって、あれはどういう仕様だったっけ、と振り返る。コーディングエージェントを毎日使っていて、私にはこういうことがよくある。\u003C\u002Fp>\n\u003Cp>先に結論を書く。\u003Cstrong>認知負債は、AI がコードを書いた瞬間ではなく、人が考えずに承認した瞬間に生まれる\u003C\u002Fstrong>。AI は書く負荷を引き受けた代わりに、読む負荷を人に残した。読むのは重いので、AI の計画や差分は流し見のまま承認される。そこで、コードの中身が人の頭に戻ってこなくなる。\u003C\u002Fp>\n\u003Cp>ただ、承認には 2 つの段階がある。考えずに承認すれば、負債は確実に生まれる。そして、理解したうえで承認しても、後で残っていないことがある。冒頭の場面は後者だ。前者には打てる手がある。後者については、私はまだ答えを持っていない。\u003C\u002Fp>\n\u003Cp>認知負債（cognitive debt。認知的負債とも書く）は、ソフトウェア工学の研究者 Margaret-Anne Storey が「チームの共有理解が時間とともに侵食されること」と定義した言葉だ。実務の記事では「理解負債」と呼ばれることも多い。\u003C\u002Fp>\n\u003Cp>私は 6 月の記事「\u003Ca href=\"https:\u002F\u002Fzenn.dev\u002Fyoshihiko555\u002Farticles\u002F78191b5e470806\" target=\"_blank\" rel=\"noopener noreferrer\">AIは人を減らさない、守備範囲を広げる\u003C\u002Fa>」で、技術的負債と意図負債は自動レビューや品質ゲート、ADR でかなり潰せる、厄介なのは AI 以前からある認知負債だ、と書いた。今はそこを一部改めたい。変わった点は 2 つある。意図負債は ADR を書くだけでは潰しきれない。認知負債は AI 以前からある問題だが、AI がその溜まる速さを上げている。一方で、技術的負債は AI のレビューと品質ゲートでかなり減らせるという見立ては変わらない。ただし AI のレビューで減るのはコードの問題で、人の理解は増えない。Storey 自身も論文で「生成 AI は技術的負債を減らしながら、認知負債と意図負債の蓄積を速めうる」と書いている。\u003C\u002Fp>\n\u003Ch2 id=\"ai-コーディングで認知負荷と認知負債が同時に増えている\" tabindex=\"-1\">\u003Cspan class=\"h-no\" aria-hidden=\"true\">01\u003C\u002Fspan>AI コーディングで認知負荷と認知負債が同時に増えている\u003C\u002Fh2>\n\u003Cp>AI は書く負荷を下げたが、読む負荷と、理解が抜けていく速さを上げた。いま現場で起きていることの多くは、この 2 つの組み合わせで説明できる。\u003C\u002Fp>\n\u003Cp>私自身、AI に実装を任せた部分は頭に入ってきにくい。それで困った、あるいは困りそうだと感じたのは、変更や障害対応のとき、人に説明しようとしたとき、レビューで承認するとき、設計の選択を迫られたときだ。\u003C\u002Fp>\n\u003Cp>この記事で「承認」と呼ぶのは、AI が出してきた計画や差分を受け入れることだ。Plan Mode で実装方針に「はい」と答えるのも、差分を見てマージするのも、どちらも承認である。\u003C\u002Fp>\n\u003Ch3 id=\"承認が形だけになる\" tabindex=\"-1\">承認が形だけになる\u003C\u002Fh3>\n\u003Cp>コードの生成速度が人の読む速度を超えた。twada さん（和田卓人さん）の講演「負債のメタファと2026年」でも、レビューが形骸化し始めていると指摘されていた。Addy Osmani は「\u003Ca href=\"https:\u002F\u002Faddyosmani.com\u002Fblog\u002Fcomprehension-debt\u002F\" target=\"_blank\" rel=\"noopener noreferrer\">Comprehension Debt\u003C\u002Fa>」で、「レビューされたコードは理解されたコードだ」という前提はもう成り立たない、と書いている。承認のボタンは押されている。だが、中身を読んで判断した結果とは限らない。\u003C\u002Fp>\n\u003Ch3 id=\"チームの誰もシステムを説明できなくなる\" tabindex=\"-1\">チームの誰もシステムを説明できなくなる\u003C\u002Fh3>\n\u003Cp>認知負債は、人が辞めなくても溜まる。以前は、メンバーが抜けて理解が失われるのが典型だった。いまは全員がそろったまま、誰も説明できない部分が増えていく。そうなると、変更は当てずっぽうになり、障害対応は博打になる。twada さんの講演の言葉を借りれば、AI も直せない障害が起きたとき、直せる人がいない。責任の空白である。\u003C\u002Fp>\n\u003Ch3 id=\"理解が欠けても速度の指標には表れない\" tabindex=\"-1\">理解が欠けても速度の指標には表れない\u003C\u002Fh3>\n\u003Cp>技術的負債はコードを開けば見える。認知負債は見えない。理解の欠け具合を測る指標もまだない。一方で、デプロイ頻度やリードタイムのような速度の指標は、設計の理解を置き去りにしても上げられる。twada さんはこれを「『生産性』を上げたい組織と個人の共犯関係が成り立ってしまう」と表現していた。評価が速さを褒め続ける限り、理解に時間を使う理由は生まれない。\u003C\u002Fp>\n\u003Cp>若手にとってはなお厳しい。6 月の記事「\u003Ca href=\"https:\u002F\u002Fzenn.dev\u002Fyoshihiko555\u002Farticles\u002F807763e547a27c\" target=\"_blank\" rel=\"noopener noreferrer\">AIは若手を奪わない、判断の回数を増やす\u003C\u002Fa>」で書いたとおり、判断の基礎は自分で判断した回数で育つ。AI の案を承認するだけの毎日では、その回数が増えない。\u003C\u002Fp>\n\u003Ch2 id=\"3-つの負債を「下り」と「上り」で整理する\" tabindex=\"-1\">\u003Cspan class=\"h-no\" aria-hidden=\"true\">02\u003C\u002Fspan>3 つの負債を「下り」と「上り」で整理する\u003C\u002Fh2>\n\u003Cp>意図負債は、人の意図がコードになるまでの「下り」でずれる。認知負債は、コードの中身が人の頭に戻る「上り」で抜ける。こう分けると、2 つの負債の重なりと違いが見えやすい。\u003C\u002Fp>\n\u003Cp>Storey は負債を 3 層に分けた（\u003Ca href=\"https:\u002F\u002Farxiv.org\u002Fabs\u002F2603.22106\" target=\"_blank\" rel=\"noopener noreferrer\">arXiv:2603.22106\u003C\u002Fa>）。\u003C\u002Fp>\n\u003Cdiv class=\"tbl\" tabindex=\"0\" role=\"region\" aria-label=\"Table\">\u003Ctable>\n\u003Cthead>\n\u003Ctr>\n\u003Cth>負債\u003C\u002Fth>\n\u003Cth>宿る場所\u003C\u002Fth>\n\u003Cth>Storey の定義（筆者訳）\u003C\u002Fth>\n\u003C\u002Ftr>\n\u003C\u002Fthead>\n\u003Ctbody>\n\u003Ctr>\n\u003Ctd>技術的負債\u003C\u002Ftd>\n\u003Ctd>コード\u003C\u002Ftd>\n\u003Ctd>コードの層にある問題\u003C\u002Ftd>\n\u003C\u002Ftr>\n\u003Ctr>\n\u003Ctd>認知負債\u003C\u002Ftd>\n\u003Ctd>人\u003C\u002Ftd>\n\u003Ctd>チームの共有理解が時間とともに侵食される\u003C\u002Ftd>\n\u003C\u002Ftr>\n\u003Ctr>\n\u003Ctd>意図負債\u003C\u002Ftd>\n\u003Ctd>要求・ADR・計画・テストなどの記録\u003C\u002Ftd>\n\u003Ctd>目標・制約・根拠が外に書き出されていない\u003C\u002Ftd>\n\u003C\u002Ftr>\n\u003C\u002Ftbody>\n\u003C\u002Ftable>\u003C\u002Fdiv>\n\u003Cp>なお、MIT の Kosmyna らも「認知的負債」という言葉を使っている。こちらは LLM に頼ったときの個人の思考力の話で、Storey とは系統が別だ（最後の章で少し触れる）。\u003C\u002Fp>\n\u003Cp>\u003Cimg src=\"\u002F\u002Fimages.ctfassets.net\u002Fd3b1looh8iwg\u002F6COpAHyV4YsilT4CYmX9Nb\u002F1ae685d442b1699429b29d6007e5c53a\u002F01_down-up-debt.png\" alt=\"01 down-up-debt\" loading=\"lazy\">\u003C\u002Fp>\n\u003Ch3 id=\"意図負債は「下り」でずれる\" tabindex=\"-1\">意図負債は「下り」でずれる\u003C\u002Fh3>\n\u003Cp>人の意図が AI を経てコードになるまでに、意図は 3 か所でずれる。\u003C\u002Fp>\n\u003Col>\n\u003Cli>指示の足りない部分を、AI がもっともらしく埋める\u003C\u002Fli>\n\u003Cli>実装の途中で、小さな判断を AI が黙って下す\u003C\u002Fli>\n\u003Cli>後で読むと、ADR や計画に書かれた意図が、自分のものか AI のものか分からない\u003C\u002Fli>\n\u003C\u002Fol>\n\u003Cp>3 つ目が特に厄介だ。たとえば、AI に書かせた ADR の「この方式を選んだ理由」の欄を考えてみる。読めば筋は通っている。だが、それが自分で考えて決めた理由なのか、AI が後から補った理由なのかは、もう区別できない。twada さんも、AI が生成したドキュメントに残る「意図」の多くは AI が行間をもっともらしく埋めた結果で、人の判断と見分けがつきにくい、と指摘していた。\u003C\u002Fp>\n\u003Cp>だから、ADR を書くだけでは意図負債は潰しきれない。記録は残る。だが、それが人の意図だという保証がない。ここが、6 月に私が楽観しすぎていた点だ。\u003C\u002Fp>\n\u003Ch3 id=\"認知負債は「上り」で抜ける\" tabindex=\"-1\">認知負債は「上り」で抜ける\u003C\u002Fh3>\n\u003Cp>上りはコードの中身が人の頭に戻ってくる流れだ。自分で書いていた頃は、書くこと自体がこの流れを作っていた。AI に任せると、その流れは承認の場面にしか残らない。承認は、理解が人に戻る最後の関所になる。そこを流し見で通れば、理解は戻らない。\u003C\u002Fp>\n\u003Ch2 id=\"承認で負債が生まれる理由\" tabindex=\"-1\">\u003Cspan class=\"h-no\" aria-hidden=\"true\">03\u003C\u002Fspan>承認で負債が生まれる理由\u003C\u002Fh2>\n\u003Cp>AI は書く負荷を引き受けた。その分、人には読む負荷が残った。自分で書いていないコードを読んで正しさを確かめるのは、書くより重いことが多い。だから承認は流し見になる。\u003C\u002Fp>\n\u003Cp>ここで言う認知負荷は作業中に頭にかかる負担のことだ。負荷はその場の負担で、負債は時間とともに溜まっていくもの。読む負荷が重すぎて流し見になり、流し見の承認が積み重なって負債になる。この記事では負荷と負債の関係をそう捉えている。\u003C\u002Fp>\n\u003Cp>\u003Cimg src=\"\u002F\u002Fimages.ctfassets.net\u002Fd3b1looh8iwg\u002F7t4LpyCsLOjXbojHASNnN\u002F2e9404ac11dce427b152f99f284d164a\u002F03_write-load-to-read-load.png\" alt=\"03_write-load-to-read-load\" loading=\"lazy\">\u003C\u002Fp>\n\u003Ch3 id=\"書くことは理解する手段でもあった\" tabindex=\"-1\">書くことは理解する手段でもあった\u003C\u002Fh3>\n\u003Cp>AI 以前は、自分でコードを書くことで、そのコードを理解できた。Peter Naur は 1985 年の論文「Programming as Theory Building」で、プログラミングの本質は、問題がどう解かれるかという「理論」をプログラマが頭の中に築くことだと論じた。その理論はコードや文書だけでは表しきれない。書く手間と摩擦を通して、この理論が頭の中にできていた。\u003C\u002Fp>\n\u003Cp>twada さんは講演で、技術的負債という比喩が生まれた 1992 年と今とを対比していた。1992 年は「人間達の理解が先行し、コードがついてきていない状態」だった。2026 年は「AI によるコード生成が先行し、人間の理解がついてきていない状態」だ。34 年で構図が逆転した。\u003C\u002Fp>\n\u003Cp>\u003Cimg src=\"\u002F\u002Fimages.ctfassets.net\u002Fd3b1looh8iwg\u002F6rs4qtxq1RARsuuSmI5Psc\u002Fe24e272b4fe83c4d03153a23d11a6aaf\u002F02_inversion-1992-2026.png\" alt=\"1992 年は人の理解が先行してコードが追いつかず、2026 年は AI の生成が先行して人の理解が追いつかない、という構図の逆転を示す図\" loading=\"lazy\">\u003C\u002Fp>\n\u003Ch3 id=\"6-月の記事との線引き\" tabindex=\"-1\">6 月の記事との線引き\u003C\u002Fh3>\n\u003Cp>6 月の若手の記事では「手を動かす基礎は AI に任せていい」と書いた。今もそう思っている。シンタックスや定型コードを書く力は任せてよい。\u003C\u002Fp>\n\u003Cp>ただ、書くことにはもう一つの役割があった。そのシステムを理解する手段だ。任せてよいのはスキルとしての「書く」で、理解の手段としての「書く」は、任せた時点で失われる。その穴は別の方法で埋める必要がある。\u003C\u002Fp>\n\u003Cp>6 月には、AI と壁打ちすれば判断の回数を増やせる、とも書いた。この回数は自分で判断した回数のことだ。AI の推奨を承認しただけの回は、数に入らない。\u003C\u002Fp>\n\u003Ch3 id=\"認知的降伏\" tabindex=\"-1\">認知的降伏\u003C\u002Fh3>\n\u003Cp>AI の出力は流暢で、自信ありげに見える。そのため人は自分で考えずに判断を委ねてしまう。Shaw と Nave は 2026 年のワーキングペーパー（未査読）で、この傾向を「認知的降伏（cognitive surrender）」と呼んだ。twada さんのスライドでは、判断・労力・責任を AI の出力に委ねてしまう傾向と説明されている。\u003C\u002Fp>\n\u003Cp>二人は人の思考を速い直感（システム 1）と遅い熟慮（システム 2）に分ける考え方に、AI という外の認知を「システム 3」として加えた。twada さんのスライドの説明では、熟慮は自動では動かない。直感が「何かおかしい」と引っかかったときに、はじめて動き出す。ところが AI の流暢な出力は、この引っかかりを生まない。読み手はそれを詳しい人の意見のように受け取り、AI の答えがそのまま自分の答えになる。\u003C\u002Fp>\n\u003Cp>Addy Osmani の紹介によれば、研究は 3 つの実験、参加者 1,372 人で行われた。厄介なのは、AI が間違っていたときでさえ人の自信が上がることだ。だから本人は降伏していることに気づけない。\u003C\u002Fp>\n\u003Cp>Osmani は「\u003Ca href=\"https:\u002F\u002Faddyosmani.com\u002Fblog\u002Fcognitive-surrender\u002F\" target=\"_blank\" rel=\"noopener noreferrer\">Cognitive Surrender\u003C\u002Fa>」で、任せることと明け渡すことを分けている。AI に作業を任せても、答えを自分のものとして持っているなら、それは任せただけ（offloading）だ。AI の出力が気づかないうちに自分の出力になり、自分で答えを組み立てるのをやめたとき、それが降伏（surrender）だという。この区別は次の章で書く線引きに近い。実装の細部は任せてよい。意図と設計の判断まで明け渡すと、降伏になる。\u003C\u002Fp>\n\u003Cp>twada さんのスライドには「AI が選択肢を作って人が選ぶだけでは理解は育ちにくい」とある。私にも覚えがある。AI が推奨つきの選択肢を出してくると、私はその推奨を選ぶだけになる。計画も同じで、AI が「この方針でいきます」と出したものを、割とそのまま承認する。この流れで理解のステップを踏まないと、AI の出力を流し見しただけになり、自分のインプットにならない。\u003C\u002Fp>\n\u003Ch3 id=\"承認には-2-つの段階がある\" tabindex=\"-1\">承認には 2 つの段階がある\u003C\u002Fh3>\n\u003Cul>\n\u003Cli>考えずに承認すると、負債は確実に生まれる。この記事の対策は主にこの段階に効く。\u003C\u002Fli>\n\u003Cli>理解して承認したのに、後で残っていない。この段階は最後の章で扱う。\u003C\u002Fli>\n\u003C\u002Ful>\n\u003Cp>\u003Cimg src=\"\u002F\u002Fimages.ctfassets.net\u002Fd3b1looh8iwg\u002F3wpwBa7T8VCk5iTxpH7mIH\u002F47d682b12b24b535f2c8e18bd68f7566\u002F04_two-stages-of-approval.png\" alt=\"04 two-stages-of-approval\" loading=\"lazy\">\u003C\u002Fp>\n\u003Ch2 id=\"反論:-理解を手放して要るときに作り直せばいいのでは\" tabindex=\"-1\">\u003Cspan class=\"h-no\" aria-hidden=\"true\">04\u003C\u002Fspan>反論: 理解を手放して要るときに作り直せばいいのでは\u003C\u002Fh2>\n\u003Cp>実装の細部についてはこの反論に賛成する。意図と設計については賛成しない。\u003C\u002Fp>\n\u003Cp>人の理解に頼るのをやめようという立場がある。型・テスト・監視で振る舞いを守り、必要になったら AI に説明させて理解し直せばいい、という考え方だ。James Phoenix の「\u003Ca href=\"https:\u002F\u002Funderstandingdata.com\u002Fposts\u002Fcomprehension-debt-is-refinanceable\u002F\" target=\"_blank\" rel=\"noopener noreferrer\">Comprehension Debt Is Refinanceable\u003C\u002Fa>」は、理解を増やすより、理解を作り直すコストを下げるほうがよいと論じている。\u003C\u002Fp>\n\u003Cp>実装の細部なら、私も手放してよいと思う。関数の中身を全部覚えておく必要はない。振る舞いはテストが守ってくれる。euglena1215 さんの「\u003Ca href=\"https:\u002F\u002Feuglena1215.hatenablog.jp\u002Fentry\u002F2026\u002F09\u002F27\u002F113320\" target=\"_blank\" rel=\"noopener noreferrer\">理解をどこまで手放すかは、リスク許容度と仕組みで決まる\u003C\u002Fa>」も、実装の理解は手放してよく、意図は人の記憶に頼らず残すべきだとしていて、私の立場に近い。\u003C\u002Fp>\n\u003Cp>それでも、意図と設計の理解は手放せない。理由は 2 つある。\u003C\u002Fp>\n\u003Cp>1 つ目は意図が判断した瞬間にしか残せないことだ。twada さんも、意図を捉える一番よいタイミングは重要な判断を下す瞬間で、後から取り戻すのは難しい、時には不可能だと述べていた。後から AI に説明させても、出てくるのはコードから逆算したもっともらしい理由で、当時の判断そのものではない。\u003C\u002Fp>\n\u003Cp>2 つ目は作り直した説明が正しいかを判断する人が要ることだ。その人がいなければ、最初の章で書いた責任の空白に戻る。\u003C\u002Fp>\n\u003Cp>ただし、最後の章で書く問題が本当なら、この反論の側に分がある。\u003C\u002Fp>\n\u003Ch2 id=\"個人でできること\" tabindex=\"-1\">\u003Cspan class=\"h-no\" aria-hidden=\"true\">05\u003C\u002Fspan>個人でできること\u003C\u002Fh2>\n\u003Cp>下りでは意図を先に書く。上りでは承認する前に自分の言葉で出す。私が一番効いていると感じているのは後者だ。\u003C\u002Fp>\n\u003Ch3 id=\"意図と完了条件を先に書く\" tabindex=\"-1\">意図と完了条件を先に書く\u003C\u002Fh3>\n\u003Cp>AI に渡す前に、何をしたいのか、何ができたら終わりなのかを、自分の言葉で書く。Qiita の記事「\u003Ca href=\"https:\u002F\u002Fqiita.com\u002FSicut_study\u002Fitems\u002Fb9e38c0584d4aa720d31\" target=\"_blank\" rel=\"noopener noreferrer\">【未来を解説】AIでエンジニア格差を生み出す質とスピードの考え方\u003C\u002Fa>」も、まずこの 1 つを勧めている。\u003C\u002Fp>\n\u003Cp>書く形は何でもいい。例を置いておく。最後の欄は下りで起きる「途中の小さな判断を AI が黙って下す」を減らすためのものだ。\u003C\u002Fp>\n\u003Cfigure class=\"code\" data-lang=\"markdown\">\u003Cdiv class=\"code-bar\">\u003Cspan class=\"lang\">MARKDOWN\u003C\u002Fspan>\u003Cspan>12 LINES\u003C\u002Fspan>\u003Cbutton class=\"copy\" type=\"button\" data-cursor=\"COPY\">COPY\u003C\u002Fbutton>\u003C\u002Fdiv>\u003Cpre class=\"shiki site-code\" style=\"background-color:var(--shiki-background);color:var(--shiki-foreground)\" tabindex=\"0\">\u003Ccode class=\"language-markdown\">\u003Cspan class=\"line\">\u003Cspan style=\"color:var(--shiki-foreground);font-weight:bold\">## やりたいこと\u003C\u002Fspan>\u003C\u002Fspan>\n\u003Cspan class=\"line\">\u003C\u002Fspan>\n\u003Cspan class=\"line\">\u003Cspan style=\"color:var(--shiki-foreground)\">- 何を、なぜ変えるか（1〜2 行）\u003C\u002Fspan>\u003C\u002Fspan>\n\u003Cspan class=\"line\">\u003C\u002Fspan>\n\u003Cspan class=\"line\">\u003Cspan style=\"color:var(--shiki-foreground);font-weight:bold\">## 完了条件\u003C\u002Fspan>\u003C\u002Fspan>\n\u003Cspan class=\"line\">\u003C\u002Fspan>\n\u003Cspan class=\"line\">\u003Cspan style=\"color:var(--shiki-foreground)\">- 何ができたら終わりか。どう確かめるか\u003C\u002Fspan>\u003C\u002Fspan>\n\u003Cspan class=\"line\">\u003C\u002Fspan>\n\u003Cspan class=\"line\">\u003Cspan style=\"color:var(--shiki-foreground);font-weight:bold\">## 決めていること \u002F 決めていないこと\u003C\u002Fspan>\u003C\u002Fspan>\n\u003Cspan class=\"line\">\u003C\u002Fspan>\n\u003Cspan class=\"line\">\u003Cspan style=\"color:var(--shiki-foreground)\">- 決めている: 使う方式、触らないファイルなど\u003C\u002Fspan>\u003C\u002Fspan>\n\u003Cspan class=\"line\">\u003Cspan style=\"color:var(--shiki-foreground)\">- 決めていない: AI に提案してほしいこと。勝手に決めずに聞いてほしいこと\u003C\u002Fspan>\u003C\u002Fspan>\u003C\u002Fcode>\u003C\u002Fpre>\n\u003C\u002Ffigure>\n\u003Ch3 id=\"大きい変更のときは計画を図解させる\" tabindex=\"-1\">大きい変更のときは計画を図解させる\u003C\u002Fh3>\n\u003Cp>私は大きい変更だと感じたときや ADR を書くときに、計画が何をしようとしているのかを AI に図解させ、それを読んでから進めている。基準は決めておらず、自分の感覚で判断している。毎回やると重いからだ。twada さんも講演の口頭で、毎回の理解度チェックは運用コストが重く、図解に寄せていった、という趣旨の話をしていた（スライドには載っていない。私の聞き取りによる）。\u003C\u002Fp>\n\u003Cp>頼み方の例を置いておく。\u003C\u002Fp>\n\u003Cfigure class=\"code\" data-lang=\"text\">\u003Cdiv class=\"code-bar\">\u003Cspan class=\"lang\">TEXT\u003C\u002Fspan>\u003Cspan>5 LINES\u003C\u002Fspan>\u003Cbutton class=\"copy\" type=\"button\" data-cursor=\"COPY\">COPY\u003C\u002Fbutton>\u003C\u002Fdiv>\u003Cpre class=\"shiki site-code\" style=\"background-color:var(--shiki-background);color:var(--shiki-foreground)\" tabindex=\"0\">\u003Ccode class=\"language-text\">\u003Cspan class=\"line\">\u003Cspan>実装に入る前に、この計画を図で説明してください。\u003C\u002Fspan>\u003C\u002Fspan>\n\u003Cspan class=\"line\">\u003Cspan>- 変更前と変更後で、モジュールどうしの関係がどう変わるか\u003C\u002Fspan>\u003C\u002Fspan>\n\u003Cspan class=\"line\">\u003Cspan>- データがどこから来て、どこへ行くか\u003C\u002Fspan>\u003C\u002Fspan>\n\u003Cspan class=\"line\">\u003Cspan>- この計画の中で、私に確認せずに決めたことがあれば列挙する\u003C\u002Fspan>\u003C\u002Fspan>\n\u003Cspan class=\"line\">\u003Cspan>図は Mermaid で。説明は図 1 枚につき 3 行まで。\u003C\u002Fspan>\u003C\u002Fspan>\u003C\u002Fcode>\u003C\u002Fpre>\n\u003C\u002Ffigure>\n\u003Cp>ただし、図は分かった気にさせやすい。twada さんのスライドにも、豊かな形式のほうが理解は進むが、同時に認知的降伏のリスクも高まる、と注意がある。図を読んで終わりにしない。\u003C\u002Fp>\n\u003Ch3 id=\"承認する前に自分の言葉で説明する\" tabindex=\"-1\">承認する前に自分の言葉で説明する\u003C\u002Fh3>\n\u003Cp>図を読んだら、承認する前に、計画が何をするのかを自分の言葉で書いてみる。3 行でいい。書けなければ、まだ理解していない。\u003C\u002Fp>\n\u003Cp>twada さんのスライドはこれをプロテジェ効果として紹介している。他者に説明しようとすると、自分の理解の足りなさがはっきりし、知識が定着して本当の理解につながる。私はアウトプットが認知負債を埋めるのに一番有効な方法だと感じている。\u003C\u002Fp>\n\u003Ch2 id=\"チームでできること\" tabindex=\"-1\">\u003Cspan class=\"h-no\" aria-hidden=\"true\">06\u003C\u002Fspan>チームでできること\u003C\u002Fh2>\n\u003Cp>個人の対策をチームの仕組みに移す。理解を関門にする、説明し合う場を作る、評価の物差しを変える、の 3 つだ。\u003C\u002Fp>\n\u003Ch3 id=\"理解を関門にする\" tabindex=\"-1\">理解を関門にする\u003C\u002Fh3>\n\u003Cp>大きい変更はマージする前に、変更した人が中身を説明できるかを確かめる。twada さんのスライドでも、Plan Mode を抜けるときに理解をチェックする試みが紹介されている。全部の PR でやると回らないので、対象は大きい変更に絞る。個人の図解と同じ考え方だ。\u003C\u002Fp>\n\u003Ch3 id=\"説明し合う場を作る\" tabindex=\"-1\">説明し合う場を作る\u003C\u002Fh3>\n\u003Cp>設計の説明会でも、ペア作業でもいい。誰かに説明する機会をチームで用意する。個人のアウトプットと同じ効果があるうえに、一人の頭の中にあった理解がチームのものになる。認知負債はチームの共有理解の問題なので、ここが一番効くはずだ。\u003C\u002Fp>\n\u003Ch3 id=\"評価の物差しを変える\" tabindex=\"-1\">評価の物差しを変える\u003C\u002Fh3>\n\u003Cp>速度を上げても、理解が欠けていれば意味がない。理解は測りにくいが、速さだけを褒めるのはやめられる。たとえば振り返りで「何件出したか」と一緒に「その変更を説明できるか」を聞く。それだけでも、理解に時間を使う理由ができる。\u003C\u002Fp>\n\u003Cp>最初の章の課題とこの章の対策はこう対応する。関門と説明の場は理解を人に戻す上りに効く。評価の物差しは意図を書く時間と理解する時間を作るので、上りと下りの両方に効く。\u003C\u002Fp>\n\u003Cp>\u003Cimg src=\"\u002F\u002Fimages.ctfassets.net\u002Fd3b1looh8iwg\u002F3EFHukqbPOlxk7c2XYLNw2\u002F0202253d10e735094e352c568ed392c2\u002F05_team-measures.png\" alt=\"05 team-measures\" loading=\"lazy\">\u003C\u002Fp>\n\u003Ch2 id=\"理解して承認しても残らない問題\" tabindex=\"-1\">\u003Cspan class=\"h-no\" aria-hidden=\"true\">07\u003C\u002Fspan>理解して承認しても残らない問題\u003C\u002Fh2>\n\u003Cp>最後に、答えの出ていない問題を書いておく。\u003C\u002Fp>\n\u003Cp>図解させて AI の出力を読み、その場では理解したうえで承認する。それでも後になって、あれはどういう仕様だったっけ、と振り返ることがよくある。ここまでの対策は承認の時点の理解には効く。だが、時間がたっても残ることまでは保証しない。\u003C\u002Fp>\n\u003Cp>これは私だけの話ではないかもしれない。MIT の Kosmyna らの研究（\u003Ca href=\"https:\u002F\u002Farxiv.org\u002Fabs\u002F2506.08872\" target=\"_blank\" rel=\"noopener noreferrer\">arXiv:2506.08872\u003C\u002Fa>）では、LLM を使ってエッセイを書いた群の 83.3%（18 人中 15 人）が、書いた後に自分の文を正しく引用できなかった。検索エンジンを使った群と、何も使わなかった群では、どちらも 11.1%（18 人中 2 人）だった。未査読のプレプリントで、被験者は 54 人、課題は短いエッセイなので、そのまま開発に当てはめることはできない。ただ、自分で関わったはずのものが手元に残らないという点は、私の感覚に近い。\u003C\u002Fp>\n\u003Cp>これが本当なら、前の章の反論の側に分がある。理解は守っても残らないのだから、作り直せるようにしておくほうが現実的だ、と。それでも私は、意図と設計は手放せないと考えている。では、残らない理解をどう残すのか。あるいは残らない前提で意図をどう守るのか。そこはまだ分からない。\u003C\u002Fp>\n\u003Ch2 id=\"まとめ\" tabindex=\"-1\">\u003Cspan class=\"h-no\" aria-hidden=\"true\">08\u003C\u002Fspan>まとめ\u003C\u002Fh2>\n\u003Cp>認知負債は、AI がコードを書いた瞬間ではなく、人が考えずに承認した瞬間に生まれる。意図は下りでずれ、理解は上りで抜ける。実装の細部の理解は手放してよいが、意図と設計の理解は手放せない。\u003C\u002Fp>\n\u003Cp>次に大きい変更を AI に任せるとき、2 つだけ試してほしい。\u003C\u002Fp>\n\u003Col>\n\u003Cli>渡す前に、意図と完了条件を 3 行で書く\u003C\u002Fli>\n\u003Cli>承認する前に、計画を自分の言葉で 3 行で説明する\u003C\u002Fli>\n\u003C\u002Fol>\n\u003Cp>どちらも考えずに承認するのを防ぐためのものだ。理解して承認しても残らない方は、私もまだ悩んでいる。\u003C\u002Fp>\n\u003Ch2 id=\"参考文献\" tabindex=\"-1\">\u003Cspan class=\"h-no\" aria-hidden=\"true\">09\u003C\u002Fspan>参考文献\u003C\u002Fh2>\n\u003Cul>\n\u003Cli>和田卓人「\u003Ca href=\"https:\u002F\u002Fspeakerdeck.com\u002Ftwada\u002Fdebt-metaphor-in-agentic-engineering-age-202609-edition\" target=\"_blank\" rel=\"noopener noreferrer\">負債のメタファと2026年\u003C\u002Fa>」技術的負債に向き合うConference 2026、2026-09-17\u003C\u002Fli>\n\u003Cli>Margaret-Anne Storey, "\u003Ca href=\"https:\u002F\u002Farxiv.org\u002Fabs\u002F2603.22106\" target=\"_blank\" rel=\"noopener noreferrer\">From Technical Debt to Cognitive and Intent Debt: Rethinking Software Health in the Age of AI\u003C\u002Fa>", arXiv:2603.22106, 2026（\u003Ca href=\"https:\u002F\u002Fqueue.acm.org\u002Fdetail.cfm?id=3807966\" target=\"_blank\" rel=\"noopener noreferrer\">ACM Queue 版\u003C\u002Fa>）\u003C\u002Fli>\n\u003Cli>Steven D. Shaw, Gideon Nave, "\u003Ca href=\"https:\u002F\u002Fosf.io\u002Fn84tx\" target=\"_blank\" rel=\"noopener noreferrer\">Thinking—Fast, Slow, and Artificial: How AI is Reshaping Human Reasoning and the Rise of Cognitive Surrender\u003C\u002Fa>", 2026（ワーキングペーパー、未査読）\u003C\u002Fli>\n\u003Cli>Nataliya Kosmyna ほか, "\u003Ca href=\"https:\u002F\u002Farxiv.org\u002Fabs\u002F2506.08872\" target=\"_blank\" rel=\"noopener noreferrer\">Your Brain on ChatGPT: Accumulation of Cognitive Debt when Using an AI Assistant for Essay Writing Task\u003C\u002Fa>", arXiv:2506.08872, 2025（プレプリント、未査読）\u003C\u002Fli>\n\u003Cli>Peter Naur, "Programming as Theory Building", Microprocessing and Microprogramming 15(5), 1985\u003C\u002Fli>\n\u003Cli>Addy Osmani, "\u003Ca href=\"https:\u002F\u002Faddyosmani.com\u002Fblog\u002Fcomprehension-debt\u002F\" target=\"_blank\" rel=\"noopener noreferrer\">Comprehension Debt\u003C\u002Fa>", 2026\u003C\u002Fli>\n\u003Cli>Addy Osmani, "\u003Ca href=\"https:\u002F\u002Faddyosmani.com\u002Fblog\u002Fcognitive-surrender\u002F\" target=\"_blank\" rel=\"noopener noreferrer\">Cognitive Surrender\u003C\u002Fa>", 2026-05-05\u003C\u002Fli>\n\u003Cli>James Phoenix, "\u003Ca href=\"https:\u002F\u002Funderstandingdata.com\u002Fposts\u002Fcomprehension-debt-is-refinanceable\u002F\" target=\"_blank\" rel=\"noopener noreferrer\">Comprehension Debt Is Refinanceable\u003C\u002Fa>", 2026\u003C\u002Fli>\n\u003Cli>euglena1215「\u003Ca href=\"https:\u002F\u002Feuglena1215.hatenablog.jp\u002Fentry\u002F2026\u002F09\u002F27\u002F113320\" target=\"_blank\" rel=\"noopener noreferrer\">理解をどこまで手放すかは、リスク許容度と仕組みで決まる\u003C\u002Fa>」2026-09-27\u003C\u002Fli>\n\u003Cli>Watanabe Jin「\u003Ca href=\"https:\u002F\u002Fqiita.com\u002FSicut_study\u002Fitems\u002Fb9e38c0584d4aa720d31\" target=\"_blank\" rel=\"noopener noreferrer\">【未来を解説】AIでエンジニア格差を生み出す質とスピードの考え方\u003C\u002Fa>」Qiita\u003C\u002Fli>\n\u003C\u002Ful>\n",[459,462,464,466,468,471,473,475,477,479,482,484,487,490,492,494,496,498,500,502,504,506,508,510],{"level":426,"id":460,"text":461},"ai-コーディングで認知負荷と認知負債が同時に増えている","AI コーディングで認知負荷と認知負債が同時に増えている",{"level":419,"id":463,"text":463},"承認が形だけになる",{"level":419,"id":465,"text":465},"チームの誰もシステムを説明できなくなる",{"level":419,"id":467,"text":467},"理解が欠けても速度の指標には表れない",{"level":426,"id":469,"text":470},"3-つの負債を「下り」と「上り」で整理する","3 つの負債を「下り」と「上り」で整理する",{"level":419,"id":472,"text":472},"意図負債は「下り」でずれる",{"level":419,"id":474,"text":474},"認知負債は「上り」で抜ける",{"level":426,"id":476,"text":476},"承認で負債が生まれる理由",{"level":419,"id":478,"text":478},"書くことは理解する手段でもあった",{"level":419,"id":480,"text":481},"6-月の記事との線引き","6 月の記事との線引き",{"level":419,"id":483,"text":483},"認知的降伏",{"level":419,"id":485,"text":486},"承認には-2-つの段階がある","承認には 2 つの段階がある",{"level":426,"id":488,"text":489},"反論:-理解を手放して要るときに作り直せばいいのでは","反論: 理解を手放して要るときに作り直せばいいのでは",{"level":426,"id":491,"text":491},"個人でできること",{"level":419,"id":493,"text":493},"意図と完了条件を先に書く",{"level":419,"id":495,"text":495},"大きい変更のときは計画を図解させる",{"level":419,"id":497,"text":497},"承認する前に自分の言葉で説明する",{"level":426,"id":499,"text":499},"チームでできること",{"level":419,"id":501,"text":501},"理解を関門にする",{"level":419,"id":503,"text":503},"説明し合う場を作る",{"level":419,"id":505,"text":505},"評価の物差しを変える",{"level":426,"id":507,"text":507},"理解して承認しても残らない問題",{"level":426,"id":509,"text":509},"まとめ",{"level":426,"id":511,"text":511},"参考文献",20,{"slug":18,"title":19,"description":20,"publishedAt":21,"updatedAt":21,"category":514,"tags":515,"thumbnail":16},{"name":11,"slug":12},[516,517,518,519],{"name":25,"slug":26},{"name":28,"slug":29},{"name":31,"slug":31},{"name":33,"slug":34},[521,528,532],{"slug":18,"title":19,"description":20,"publishedAt":21,"updatedAt":21,"category":522,"tags":523,"thumbnail":16},{"name":11,"slug":12},[524,525,526,527],{"name":25,"slug":26},{"name":28,"slug":29},{"name":31,"slug":31},{"name":33,"slug":34},{"slug":36,"title":37,"description":38,"publishedAt":39,"updatedAt":39,"category":529,"tags":530,"thumbnail":16},{"name":11,"slug":12},[531],{"name":25,"slug":26},{"slug":88,"title":89,"description":90,"publishedAt":91,"updatedAt":91,"category":533,"tags":534,"thumbnail":538},{"name":11,"slug":12},[535,536,537],{"name":95,"slug":96},{"name":98,"slug":99},{"name":101,"slug":101},{"url":103,"description":104},1793725976561]