<?xml version="1.0" encoding="UTF-8"?><rss version="2.0"><channel><title>アイデアとインサイト – Autotomy</title><description>AI ファースト開発、コーディングガードレール、使い捨て前提のアーキテクチャを探求します。</description><link>https://autotomy.dev/</link><language>ja</language><item><title>mainブランチが壊れた。探すべきコミットは200個ある</title><link>https://autotomy.dev/ja/blog/git-bisect-binary-search-commit/</link><guid isPermaLink="true">https://autotomy.dev/ja/blog/git-bisect-binary-search-commit/</guid><description>git bisectは手動のコミット探索を自動化された二分探索に変える。すべてをチェックアウトすることなく、バグを導入した正確なコミットを見つける方法を解説する。</description><pubDate>Tue, 25 Aug 2026 00:00:00 GMT</pubDate></item><item><title>エラートラッカーはどこで死んだか知っている。再現には役立たない</title><link>https://autotomy.dev/ja/blog/production-crash-capture-replay/</link><guid isPermaLink="true">https://autotomy.dev/ja/blog/production-crash-capture-replay/</guid><description>スタックトレースはクラッシュの発生場所を示すが、原因ではない。ここでは、本番のクラッシュを実際にデバッグ可能なローカルテストケースに変える、キャプチャ＆リプレイのパターンを解説する。</description><pubDate>Mon, 24 Aug 2026 00:00:00 GMT</pubDate></item><item><title>テストカバレッジ94%でも見逃した整数オーバーフローを、symbolic executionが発見した</title><link>https://autotomy.dev/ja/blog/symbolic-execution-integer-overflow-coverage/</link><guid isPermaLink="true">https://autotomy.dev/ja/blog/symbolic-execution-integer-overflow-coverage/</guid><description>ユニットテストは特定の入力をチェックする。symbolic executionはあらゆる可能な入力をチェックする。仕組み、コスト、始め方を解説する。</description><pubDate>Sun, 23 Aug 2026 00:00:00 GMT</pubDate></item><item><title>ログからPIIが漏れている。grepでは救えない</title><link>https://autotomy.dev/ja/blog/pii-tracking-code-pipeline/</link><guid isPermaLink="true">https://autotomy.dev/ja/blog/pii-tracking-code-pipeline/</guid><description>ほとんどのチームは顧客からの苦情の後にPII漏洩を発見する。ここでは、機密データを取り込みから出力まで追跡し、今日から使えるコード例を紹介する。</description><pubDate>Sat, 22 Aug 2026 00:00:00 GMT</pubDate></item><item><title>CIはコードをテストしていたが、contractsは見ていなかった——だから本番でAPIが壊れた</title><link>https://autotomy.dev/ja/blog/api-contract-testing-ci/</link><guid isPermaLink="true">https://autotomy.dev/ja/blog/api-contract-testing-ci/</guid><description>ほとんどのCIパイプラインは構文エラーや論理バグを検出する。しかし、実際に本番を落とすAPI contractの破壊変更は見逃している。修正方法を解説する。</description><pubDate>Fri, 21 Aug 2026 00:00:00 GMT</pubDate></item><item><title>クラッシュの相関は嘘をつく。真のバグを指させる方法はこちら</title><link>https://autotomy.dev/ja/blog/crash-correlation-triangulation/</link><guid isPermaLink="true">https://autotomy.dev/ja/blog/crash-correlation-triangulation/</guid><description>statistical debuggingはクラッシュと相関するpredicatesを見つけるが、相関はファイル名と行番号ではない。相関スコアから実際のバグの場所へと導くランキング、フィルタリング、トライアングレーションの方法を解説する。</description><pubDate>Thu, 20 Aug 2026 00:00:00 GMT</pubDate></item><item><title>SentryのSeerはtraceを読める。だからといつも根本原因を見つけるわけではない</title><link>https://autotomy.dev/ja/blog/sentry-seer-trace-root-cause/</link><guid isPermaLink="true">https://autotomy.dev/ja/blog/sentry-seer-trace-root-cause/</guid><description>Seerはtrace tree、関連付けられたエラー、プロファイリングデータを取り込んで分散問題を診断する。実際にどう機能するか、どこで輝き、どこでまだ人間の助けを必要とするかを解説する。</description><pubDate>Wed, 19 Aug 2026 00:00:00 GMT</pubDate></item><item><title>statistical debuggingはprintfデバッグを終わらせるはずだった。ほとんどのチームはそれを動かせなかった</title><link>https://autotomy.dev/ja/blog/statistical-debugging-adoption-challenges/</link><guid isPermaLink="true">https://autotomy.dev/ja/blog/statistical-debugging-adoption-challenges/</guid><description>statistical debuggingはプログラムの動作と失敗を相関させることでバグを正確に特定することを約束した。このアイデアが研究論文から本番システムに移行しなかった理由を解説する。</description><pubDate>Tue, 18 Aug 2026 00:00:00 GMT</pubDate></item><item><title>テストはパスした。だがデータはまだ間違っている</title><link>https://autotomy.dev/ja/blog/statistical-debugging-production-data-anomalies/</link><guid isPermaLink="true">https://autotomy.dev/ja/blog/statistical-debugging-production-data-anomalies/</guid><description>statistical debuggingは本番データを信号として扱い、バグをその異常として捉える。unit testを1つも追加せずに、データの破損、オフバイワンエラー、静かな失敗を見つける方法を解説する。</description><pubDate>Mon, 17 Aug 2026 00:00:00 GMT</pubDate></item><item><title>Metamorphic testingがGCCとLLVMで147件のコンパイラバグ、自動運転車の重大欠陥を発見した。その仕組みを解説する</title><link>https://autotomy.dev/ja/blog/metamorphic-testing-production-bugs-compiler/</link><guid isPermaLink="true">https://autotomy.dev/ja/blog/metamorphic-testing-production-bugs-compiler/</guid><description>Metamorphic testingはGCC、LLVM、Vulkanシェーダコンパイラ、ADASシミュレータで実際のバグを発見してきた。この記事では、その手法を実行可能なコードとともに解説し、あなたのテストスイートのどこに位置づけるべきかを示す。</description><pubDate>Sun, 16 Aug 2026 00:00:00 GMT</pubDate></item><item><title>LLMはMetamorphic Relationsを提案できる。しかし保証はできない。</title><link>https://autotomy.dev/ja/blog/llm-metamorphic-relations-brainstorming/</link><guid isPermaLink="true">https://autotomy.dev/ja/blog/llm-metamorphic-relations-brainstorming/</guid><description>大規模言語モデルはtest oracleの発見において悪くないブレインストーミングパートナーだが、性質を幻覚し、ドメイン制約を見落とす。それらを、怪しいテストをリリースすることなく使う方法を解説する。</description><pubDate>Sat, 15 Aug 2026 00:00:00 GMT</pubDate></item><item><title>多くのMetamorphic Relationsは役に立たない。優れたものを選ぶ方法。</title><link>https://autotomy.dev/ja/blog/metamorphic-relation-quality/</link><guid isPermaLink="true">https://autotomy.dev/ja/blog/metamorphic-relation-quality/</guid><description>すべてのmetamorphic relationsがバグを捉えるわけではない。弱いrelationは虚偽の自信を与え、強いrelationだけが本当の欠陥を見つける。どう違いを見分け、実際に機能するrelationセットを構築するかを解説する。</description><pubDate>Fri, 14 Aug 2026 00:00:00 GMT</pubDate></item><item><title>正解がわからないコードはどうテストする？</title><link>https://autotomy.dev/ja/blog/metamorphic-testing-oracle-problem/</link><guid isPermaLink="true">https://autotomy.dev/ja/blog/metamorphic-testing-oracle-problem/</guid><description>Metamorphic testingを使えば、正しい出力が何かを知らなくてもコードの正しさを検証できる。その仕組み、限界、そして使い始める方法を解説する。</description><pubDate>Thu, 13 Aug 2026 00:00:00 GMT</pubDate></item><item><title>TypeScriptがその呼び出しを許さない：型システムにプロトコル状態を埋め込む方法</title><link>https://autotomy.dev/ja/blog/typescript-phantom-types-protocol-state/</link><guid isPermaLink="true">https://autotomy.dev/ja/blog/typescript-phantom-types-protocol-state/</guid><description>Phantom typesと `this` パラメータを使い、違法なプロトコル遷移を実行時のバグではなくコンパイルエラーに変える方法。</description><pubDate>Wed, 12 Aug 2026 00:00:00 GMT</pubDate></item><item><title>OpenAPIは文字を与える。Session Typesが必要とするのは文法だ。</title><link>https://autotomy.dev/ja/blog/openapi-session-types-protocol-gap/</link><guid isPermaLink="true">https://autotomy.dev/ja/blog/openapi-session-types-protocol-gap/</guid><description>OpenAPIの仕様はリクエストとレスポンスのスキーマを記述するが、有効なメッセージの順序までは規定しない。ここでは、どこまで自動抽出できるか、そしてどこに手作業で補う必要があるかを説明する。</description><pubDate>Tue, 11 Aug 2026 00:00:00 GMT</pubDate></item><item><title>セッション型は機能する。ほとんどの言語がただ実装を拒否しただけだ。</title><link>https://autotomy.dev/ja/blog/session-types-research-to-production/</link><guid isPermaLink="true">https://autotomy.dev/ja/blog/session-types-research-to-production/</guid><description>セッション型は通信プロトコルを型システムにエンコードし、実行時のプロトコルエラーをコンパイル時のエラーに変換する。プロダクションコードが使用できるようになるまでに30年間の研究論文に費やされた理由はここにある。</description><pubDate>Mon, 10 Aug 2026 00:00:00 GMT</pubDate></item><item><title>セッション型がデッドロックをコンパイルエラーに変える方法</title><link>https://autotomy.dev/ja/blog/session-types-deadlock-compiler-errors/</link><guid isPermaLink="true">https://autotomy.dev/ja/blog/session-types-deadlock-compiler-errors/</guid><description>セッション型は通信プロトコルを型システムにエンコードし、コードが実行される前にメッセージパッシングの不一致をコンパイルエラーに変える。</description><pubDate>Sun, 09 Aug 2026 00:00:00 GMT</pubDate></item><item><title>抽象解釈は博士学位が必要に聞こえる。もうそうではない</title><link>https://autotomy.dev/ja/blog/infer-abstract-interpretation-ci/</link><guid isPermaLink="true">https://autotomy.dev/ja/blog/infer-abstract-interpretation-ci/</guid><description>Inferを使ってCIパイプラインで形式的静的解析を実行する方法。動作する設定と現実的なトレードオフを紹介する。</description><pubDate>Sat, 08 Aug 2026 00:00:00 GMT</pubDate></item><item><title>LLMは静的解析の警告を優先順位付けできる。ただし、なぜかは説明できない</title><link>https://autotomy.dev/ja/blog/llm-static-analysis-triage/</link><guid isPermaLink="true">https://autotomy.dev/ja/blog/llm-static-analysis-triage/</guid><description>大規模言語モデルは静的解析の偽陽性の選別に役立つが、抽象解釈のようにプログラムの意味論を理解しているわけではない。両者を組み合わせる方法を解説する。</description><pubDate>Fri, 07 Aug 2026 00:00:00 GMT</pubDate></item><item><title>Facebookは抽象解釈でAndroidを並列化した。その仕組みを解説する。</title><link>https://autotomy.dev/ja/blog/facebook-android-abstract-interpretation-races/</link><guid isPermaLink="true">https://autotomy.dev/ja/blog/facebook-android-abstract-interpretation-races/</guid><description>Facebookがどのように抽象解釈と意図的なunsoundnessを用いて、数百万行のAndroidコードにおける競合状態を大規模に発見したか。</description><pubDate>Thu, 06 Aug 2026 00:00:00 GMT</pubDate></item><item><title>Metaはプログラムを実行しない静的解析ツールで本番コードから10万件のバグを発見した</title><link>https://autotomy.dev/ja/blog/meta-infer-100000-bugs-static-analysis/</link><guid isPermaLink="true">https://autotomy.dev/ja/blog/meta-infer-100000-bugs-static-analysis/</guid><description>MetaのInferは抽象解釈と双方向誘導を用いて、コードの構造を推論することでヌル参照、メモリリーク、競合状態を検出する。実行は不要だ。仕組みと自社コードベースでの活用方法を解説する。</description><pubDate>Wed, 05 Aug 2026 00:00:00 GMT</pubDate></item><item><title>静的解析は飛行機が墜落しないことを証明できない。だが、もっと有益なことは証明できる。</title><link>https://autotomy.dev/ja/blog/static-analysis-aviation-abstract-interpretation/</link><guid isPermaLink="true">https://autotomy.dev/ja/blog/static-analysis-aviation-abstract-interpretation/</guid><description>抽象解釈はあらゆる可能なプログラム状態を過大近似する。抽象化の中でゼロ除算が到達不可能なら、実際のコードでも到達不可能である。以下に、その仕組みと限界を解説する。</description><pubDate>Tue, 04 Aug 2026 00:00:00 GMT</pubDate></item><item><title>コードにランタイムエラーがないことを証明する方法（そして、なぜ諦めるかもしれない理由）</title><link>https://autotomy.dev/ja/blog/abstract-interpretation-runtime-error-proof/</link><guid isPermaLink="true">https://autotomy.dev/ja/blog/abstract-interpretation-runtime-error-proof/</guid><description>抽象解釈を使えば、実行前にランタイムエラーが発生しないことを証明できる。実際の仕組み、難しさ、そしてツールチェーンでの位置づけを解説する。</description><pubDate>Mon, 03 Aug 2026 00:00:00 GMT</pubDate></item><item><title>Cコードを全面的に rewrite しなくても、キャパビリティハードウェア上で動作させられる</title><link>https://autotomy.dev/ja/blog/cheri-c-porting-hybrid-abi/</link><guid isPermaLink="true">https://autotomy.dev/ja/blog/cheri-c-porting-hybrid-abi/</guid><description>CHERIのハイブリッドABIを使えば、Cコードを段階的にキャパビリティハードウェアへ移植できる。コンパイル方法、どこが壊れるか、そして codebase 全体を rewrite せずに修正する方法を解説する。</description><pubDate>Sun, 02 Aug 2026 00:00:00 GMT</pubDate></item><item><title>ケイパビリティ・ハードウェアは失敗しなかった。40年早すぎただけだ。</title><link>https://autotomy.dev/ja/blog/capability-hardware-cheri-history/</link><guid isPermaLink="true">https://autotomy.dev/ja/blog/capability-hardware-cheri-history/</guid><description>1970年代から、ハードウェアレベルでのメモリ安全性は可能だった。なぜケイパビリティ・アーキテクチャがフラット・メモリ・モデルに敗れ続けたのか、そしてなぜCHERIがついに状況を変えているのか。</description><pubDate>Sat, 01 Aug 2026 00:00:00 GMT</pubDate></item><item><title>C言語の依存ライブラリがプロセス全体をクラッシュさせる。WebAssemblyがそれを防ぐ。</title><link>https://autotomy.dev/ja/blog/c-library-wasm-sandbox/</link><guid isPermaLink="true">https://autotomy.dev/ja/blog/c-library-wasm-sandbox/</guid><description>単一のCライブラリを隔離するためにコンテナを使うのは大げさすぎる。WebAssemblyにコンパイルし、WASIサンドボックス内で実行すれば、メモリ安全性、ケイパビリティベースのファイルシステムアクセス、クラッシュ封じ込めをDockerなしで実現できる。</description><pubDate>Fri, 31 Jul 2026 00:00:00 GMT</pubDate></item><item><title>あなたのスマートフォンはすでにメモリ破損を検出するハードウェアを搭載している</title><link>https://autotomy.dev/ja/blog/mobile-memory-tagging-extension/</link><guid isPermaLink="true">https://autotomy.dev/ja/blog/mobile-memory-tagging-extension/</guid><description>ARM Memory Tagging ExtensionとGWP-ASanにより、最新のモバイルデバイスで本番環境のメモリ安全性検出が可能になった。その仕組みとトレードオフについて解説する。</description><pubDate>Thu, 30 Jul 2026 00:00:00 GMT</pubDate></item><item><title>バッファオーバーフローが頻発するのは、我々がソフトウェアで対処しているからだ</title><link>https://autotomy.dev/ja/blog/cheri-hardware-buffer-overflow-prevention/</link><guid isPermaLink="true">https://autotomy.dev/ja/blog/cheri-hardware-buffer-overflow-prevention/</guid><description>CHERIは、すべてのポインタを境界付きcapabilityに変換するハードウェア拡張である。CPUレベルでバッファオーバーフローを阻止する仕組み、コスト、および実機での試用方法を解説する。</description><pubDate>Wed, 29 Jul 2026 00:00:00 GMT</pubDate></item><item><title>LLMはコードの正しさを証明できないが、証明のための定型作業は書ける</title><link>https://autotomy.dev/ja/blog/llm-cleanroom-proof-obligation-automation/</link><guid isPermaLink="true">https://autotomy.dev/ja/blog/llm-cleanroom-proof-obligation-automation/</guid><description>クリーンルーム検証では、検証条件の生成と解消が必要である。ここでは、LLMがアノテーションとVC生成を自動化し、開発者が実際に難しい証明に集中できるようにする方法を説明する。</description><pubDate>Tue, 28 Jul 2026 00:00:00 GMT</pubDate></item><item><title>Cleanroom は 1KLOC あたり 0.1 defect を達成する。フル導入しなくてもそこに到達できる。</title><link>https://autotomy.dev/ja/blog/cleanroom-pragmatic-subset/</link><guid isPermaLink="true">https://autotomy.dev/ja/blog/cleanroom-pragmatic-subset/</guid><description>Cleanroom software engineering は defect rate を 100 倍に削減するが、フル導入には分離した test team と formal proof が必要。ここでは、overhead なしにその大半の benefit を得られる pragmatism なサブセットを紹介する。</description><pubDate>Mon, 27 Jul 2026 00:00:00 GMT</pubDate></item><item><title>IBMのZero-Defect ProcessはKLOCあたり0.1 Bugを達成した。それでも業界は見捨てた。</title><link>https://autotomy.dev/ja/blog/ibm-cleanroom-zero-defects-disappearance/</link><guid isPermaLink="true">https://autotomy.dev/ja/blog/ibm-cleanroom-zero-defects-disappearance/</guid><description>IBMのCleanroom engineeringは業界平均より100倍優れたdefect rateを達成し、その後忘れ去られた。消えた理由は、それが機能したかどうかとは無関係だった。</description><pubDate>Sun, 26 Jul 2026 00:00:00 GMT</pubDate></item><item><title>本当に1万行を零欠陥で検証した人がいるのか？IBMはやったし、その方法論は結果より奇妙だ。</title><link>https://autotomy.dev/ja/blog/ibm-cleanroom-10000-lines-zero-defects/</link><guid isPermaLink="true">https://autotomy.dev/ja/blog/ibm-cleanroom-10000-lines-zero-defects/</guid><description>Cleanroom software engineeringは、デバッグではなくmathematical verificationによって零欠陥のインクリメントを約束した。我々はIBMの実プロジェクトデータを見て、その主張が成り立ったかを確認する。</description><pubDate>Sat, 25 Jul 2026 00:00:00 GMT</pubDate></item><item><title>あなたのモジュールには3層ある。書いたのは1層だけだろう。</title><link>https://autotomy.dev/ja/blog/cleanroom-box-structure-three-layers/</link><guid isPermaLink="true">https://autotomy.dev/ja/blog/cleanroom-box-structure-three-layers/</guid><description>Box Structureは、モジュールが何をするか、何を記憶するか、どう動作するかを、3つの独立した検証可能な層として定義することを強制する。Cleanroomがどうやってデバッグを排除するか、ここで解説する。</description><pubDate>Fri, 24 Jul 2026 00:00:00 GMT</pubDate></item><item><title>IBM は開発者に自身のコード実行を禁止し、0.1 defects/KLOC のソフトウェアを出荷した</title><link>https://autotomy.dev/ja/blog/ibm-cleanroom-01-defects-per-kloc/</link><guid isPermaLink="true">https://autotomy.dev/ja/blog/ibm-cleanroom-01-defects-per-kloc/</guid><description>IBM の Cleanroom エンジニアリング・プロセスは、バグを発見するのではなく未然に防ぐことで、業界平均より 100 倍優れた defect 率を達成した。それがどう機能したか、なぜほとんど誰も使わないのか、そして今日あなたが取り入れられるものとは。</description><pubDate>Thu, 23 Jul 2026 00:00:00 GMT</pubDate></item><item><title>CI があなたなしで tangle できない限り、あなたのリテラート・プログラムは壊れている</title><link>https://autotomy.dev/ja/blog/ci-literate-programming-tangle/</link><guid isPermaLink="true">https://autotomy.dev/ja/blog/ci-literate-programming-tangle/</guid><description>Literate programming は単一事実情報源を約束するが、手動の weave と tangle のステップが CI/CD パイプラインを破壊する。Markdown ファイルを正規のものに保つため、抽出とドキュメント生成を自動化する方法を紹介する。</description><pubDate>Wed, 22 Jul 2026 00:00:00 GMT</pubDate></item><item><title>コードを先にLLMに説明したら、バグ率が85%減少した</title><link>https://autotomy.dev/ja/blog/llm-rubber-ducking-bug-rate/</link><guid isPermaLink="true">https://autotomy.dev/ja/blog/llm-rubber-ducking-bug-rate/</guid><description>30日間、LLMにコードを依頼する前に設計の説明を書き続けた。その結果は、私のrubber-duckingに対する考え方を変えた。</description><pubDate>Tue, 21 Jul 2026 00:00:00 GMT</pubDate></item><item><title>テスト、コード、散文を1つのMarkdownファイルにまとめて、ドキュメントへのコードコピーをやめた</title><link>https://autotomy.dev/ja/blog/literate-programming-markdown-python/</link><guid isPermaLink="true">https://autotomy.dev/ja/blog/literate-programming-markdown-python/</guid><description>Literate programmingは、Markdownファイルをsingle source of truthにすることで、ドキュメント、テスト、実装を同期させ続ける。Python30行で実装する方法を紹介する。</description><pubDate>Mon, 20 Jul 2026 00:00:00 GMT</pubDate></item><item><title>あなたのClaudeスレッドはすでにドキュメントです。ただ、12時間で消えてしまうだけ。</title><link>https://autotomy.dev/ja/blog/claude-thread-to-documentation/</link><guid isPermaLink="true">https://autotomy.dev/ja/blog/claude-thread-to-documentation/</guid><description>LLMの対話には意図、却下された代替案、そして動作するコードが含まれています。これこそがドキュメントであるべきものです。以下に、短寿命なチャットをナラティブを失うことなく、永続的で検索可能なドキュメントに変換する方法を説明します。</description><pubDate>Sun, 19 Jul 2026 00:00:00 GMT</pubDate></item><item><title>テキストエディタは無効なコードを書かせる。ツリーエディタはそうしない。</title><link>https://autotomy.dev/ja/blog/structured-editing-ast-text-editors/</link><guid isPermaLink="true">https://autotomy.dev/ja/blog/structured-editing-ast-text-editors/</guid><description>すべてのコンパイラはコードをツリーとして見ているが、エディタは生のテキストを編集させる。構造化編集が実際にどう見えるか、なぜ普及しなかったか、そしてツールを変えずにその利点を取り入れる方法を解説する。</description><pubDate>Sat, 18 Jul 2026 00:00:00 GMT</pubDate></item><item><title>Donald Knuthはプログラムを文学のように読めるものにしたかった。コンパイラは別の考えを持っていた。</title><link>https://autotomy.dev/ja/blog/knuth-literate-programming-history/</link><guid isPermaLink="true">https://autotomy.dev/ja/blog/knuth-literate-programming-history/</guid><description>Literate programmingは、コードは人間のために先に書かれ、機械のために次に書かれるべきだと約束した。40年後、ほとんど誰もそのように書いていない。なぜソフトウェア文書化における最もエレガントなアイデアが、私たちの働き方を変えられなかったのか。</description><pubDate>Fri, 17 Jul 2026 00:00:00 GMT</pubDate></item><item><title>バグを修正するのは簡単な部分だ。なぜそれが存在するのかを突き止めることこそが重要だ</title><link>https://autotomy.dev/ja/blog/fagan-causal-analysis-defects/</link><guid isPermaLink="true">https://autotomy.dev/ja/blog/fagan-causal-analysis-defects/</guid><description>ほとんどのチームは欠陥を修正して先に進む。同じ欠陥が戻ってくる。フェイガン検査の中で因果分析を実行し、同じバグを二度書かないようにする方法を解説する。</description><pubDate>Thu, 16 Jul 2026 00:00:00 GMT</pubDate></item><item><title>プルリクエストレビューは欠陥の15〜30%を検出する。データは50年前からそう言っている。</title><link>https://autotomy.dev/ja/blog/pr-reviews-catch-15-to-30-percent-defects/</link><guid isPermaLink="true">https://autotomy.dev/ja/blog/pr-reviews-catch-15-to-30-percent-defects/</guid><description>IBM、AT&amp;T、HP、Microsoftを対象とした複数の研究により、非公式なコードレビューが欠陥の約4分の1を検出することが確認されている。データが実際に示していること、その数値が低い理由、そして改善方法を解説する。</description><pubDate>Wed, 15 Jul 2026 00:00:00 GMT</pubDate></item><item><title>汎用的なチェックリストは何も見つけられない。構造化されたチェックリストは欠陥の60%を発見する。</title><link>https://autotomy.dev/ja/blog/fagan-structured-checklist-defect-detection/</link><guid isPermaLink="true">https://autotomy.dev/ja/blog/fagan-structured-checklist-defect-detection/</guid><description>大半のレビューチェックリストは、善意のコピペリストに過ぎない。Fagan inspectionスタイルの構造化チェックリストは、実際の欠陥データから構築され、特定のアーティファクトタイプを対象とし、個人の準備段階で使用される。機能するチェックリストの構築方法は以下の通りだ。</description><pubDate>Tue, 14 Jul 2026 00:00:00 GMT</pubDate></item><item><title>大規模言語モデルはコードの事前査読はできる。会議を運営できない。</title><link>https://autotomy.dev/ja/blog/llm-fagan-inspection-preparation/</link><guid isPermaLink="true">https://autotomy.dev/ja/blog/llm-fagan-inspection-preparation/</guid><description>フェイガン査読は250行をレビューするのに4〜6人と2時間を要する。大規模言語モデルは準備作業とチェックリストの遵守を担うことでそのコストを削減できるが、最も高価な欠陥を見つける人間の役割は代替できない。</description><pubDate>Mon, 13 Jul 2026 00:00:00 GMT</pubDate></item><item><title>Fagan Inspectionsはテスト前に90%の欠陥を発見していた。それなのに我々はやめてしまった。</title><link>https://autotomy.dev/ja/blog/fagan-inspections-disappearance-ibm/</link><guid isPermaLink="true">https://autotomy.dev/ja/blog/fagan-inspections-disappearance-ibm/</guid><description>IBMでMichael Faganが開発した構造化レビュー・プロセスは、コードがコンパイラに到達する前にほぼすべての欠陥を捉えていた。しかし、その代償として総プロジェクト工数の15〜20%を消費していた。ソフトウェア史上もっとも効果的だったこのレビュー手法がなぜ消えたのか、そしてチームが実際に失ったものは何か。</description><pubDate>Sun, 12 Jul 2026 00:00:00 GMT</pubDate></item><item><title>あなたの最高のレビュアーでも、ほとんどの欠陥を見逃している。Fagan は1976年にIBMでそれを測定した。</title><link>https://autotomy.dev/ja/blog/fagan-reviewer-defect-detection-variance/</link><guid isPermaLink="true">https://autotomy.dev/ja/blog/fagan-reviewer-defect-detection-variance/</guid><description>シニアエンジニアであっても、非構造化のレビューで欠陥のごく一部しか検出できない。Michael Fagan のIBMにおける研究がその理由を示し、構造化されたインスペクションプロセスを構築して修正した。</description><pubDate>Sat, 11 Jul 2026 00:00:00 GMT</pubDate></item><item><title>ほとんどのコードレビューは欠陥の20%しか見つけられない。Fagan Inspectionは90%を見つける。</title><link>https://autotomy.dev/ja/blog/fagan-inspections-90-percent-defects/</link><guid isPermaLink="true">https://autotomy.dev/ja/blog/fagan-inspections-90-percent-defects/</guid><description>非公式なコードレビューは欠陥の15〜30%を見つける。50年前に確立された構造化プロセスであるFagan Inspectionは、一貫して60〜90%の除去率を報告している。その仕組み、チームが避ける理由、そして軽量版の実行方法を解説する。</description><pubDate>Fri, 10 Jul 2026 00:00:00 GMT</pubDate></item><item><title>AutoVerusは40時間の証明執筆を3回のLLM呼び出しに変える。秘訣は諦めるタイミングを知ることだ。</title><link>https://autotomy.dev/ja/blog/autoverus-llm-rust-verification/</link><guid isPermaLink="true">https://autotomy.dev/ja/blog/autoverus-llm-rust-verification/</guid><description>AutoVerusはLLMエージェントのネットワークを用いてRustコードのVerus正しさ証明を生成し、SMTソルバーのフィードバックによって駆動される生成・修復・ dischargeループにより、90%以上の証明義務を自動化する。</description><pubDate>Thu, 09 Jul 2026 00:00:00 GMT</pubDate></item><item><title>LLMはRustコードを生成できる。形式的証明は全く別の問題だ。</title><link>https://autotomy.dev/ja/blog/llm-rust-formal-proofs-hallucination/</link><guid isPermaLink="true">https://autotomy.dev/ja/blog/llm-rust-formal-proofs-hallucination/</guid><description>大規模言語モデルは驚くほど質の高いRustコードを書くが、形式的証明を求めると、不変条件を幻覚で見つけ、どの検証器も受け付けない構文をでっち上げる。それらが実際に正しい部分、壊れる部分、それでも使う方法を解説する。</description><pubDate>Wed, 08 Jul 2026 00:00:00 GMT</pubDate></item><item><title>race conditionを待つのは最悪のテスト戦略だ</title><link>https://autotomy.dev/ja/blog/model-checking-race-conditions/</link><guid isPermaLink="true">https://autotomy.dev/ja/blog/model-checking-race-conditions/</guid><description>model checkingが、concurrency bugを発見するためにアプリを数日間実行することをどう凌駕するか、そして自分のコードにどう応用するか。</description><pubDate>Tue, 07 Jul 2026 00:00:00 GMT</pubDate></item><item><title>時相論理を学ばずにコードのモデル検査ができる</title><link>https://autotomy.dev/ja/blog/is-there-a-model-checker-that-doesnt-require-learning-temporal-logic/</link><guid isPermaLink="true">https://autotomy.dev/ja/blog/is-there-a-model-checker-that-doesnt-require-learning-temporal-logic/</guid><description>Kaniのような境界付きモデル検査器やAlloyのような関係モデルファインダーは、通常のアサーションと制約で性質を検証できる。活性の証明を諦める代わりに、学習曲線は週ではなく時間単位で測られる。</description><pubDate>Mon, 06 Jul 2026 00:00:00 GMT</pubDate></item><item><title>一行の証明も書かずに Rust コードの正しさを証明できるが、状態空間が代償となる</title><link>https://autotomy.dev/ja/blog/rust-model-checking-kani-state-space/</link><guid isPermaLink="true">https://autotomy.dev/ja/blog/rust-model-checking-kani-state-space/</guid><description>Kani のようなモデル検査ツールを使えば、形式的証明の代わりに表明で Rust の性質を検証できる。問題は、ループの境界が小さくないときに何が起きるかだ。</description><pubDate>Sun, 05 Jul 2026 00:00:00 GMT</pubDate></item><item><title>分散プロトコルは単体テストできないが、モデル検証はできる</title><link>https://autotomy.dev/ja/blog/distributed-protocol-model-checking-tla/</link><guid isPermaLink="true">https://autotomy.dev/ja/blog/distributed-protocol-model-checking-tla/</guid><description>分散バグはデプロイ後の修正コストが高い。モデル検証を使えば、実装コードを1行も書く前にそれらを発見できる。以下はTLA+を使った方法である。</description><pubDate>Sat, 04 Jul 2026 00:00:00 GMT</pubDate></item><item><title>環境間で `.env` ファイルをコピーすることは設定戦略ではない</title><link>https://autotomy.dev/ja/blog/infrastructure-config-dsl-per-context/</link><guid isPermaLink="true">https://autotomy.dev/ja/blog/infrastructure-config-dsl-per-context/</guid><description>インフラストラクチャチームが、環境間の差異を明示的かつ型安全にする文脈単位のDSLを使って、dev、staging、production間の設定を管理する方法。</description><pubDate>Fri, 03 Jul 2026 00:00:00 GMT</pubDate></item><item><title>文法制約付きデコーディング: すべてのトークンでLLMに有効な構文を出力させる</title><link>https://autotomy.dev/ja/blog/grammar-constrained-decoding-llm/</link><guid isPermaLink="true">https://autotomy.dev/ja/blog/grammar-constrained-decoding-llm/</guid><description>LLMはトークンを確率的にサンプリングするため、構文を幻覚させる。文法制約付きデコーディングは各ステップで語彙をフィルタリングし、構文的妥当性を保つトークンのみを出力する。</description><pubDate>Thu, 02 Jul 2026 00:00:00 GMT</pubDate></item><item><title>英語からテーマへの翻訳は簡単だ。決定論的にすることが本当の課題だ。</title><link>https://autotomy.dev/ja/blog/english-to-theme-deterministic-design-tokens/</link><guid isPermaLink="true">https://autotomy.dev/ja/blog/english-to-theme-deterministic-design-tokens/</guid><description>英語の平易な記述からデザイントークンを生成できるが、その記述をスキーマ契約とスナップショットテストを伴う限界付きコンテキストDSLとして扱う場合に限る。</description><pubDate>Wed, 01 Jul 2026 00:00:00 GMT</pubDate></item><item><title>Grammarファイルは捨てろ：DSLパーサーを普通のTypeScriptで書く</title><link>https://autotomy.dev/ja/blog/typescript-parser-combinators-dsl/</link><guid isPermaLink="true">https://autotomy.dev/ja/blog/typescript-parser-combinators-dsl/</guid><description>Bounded Context向けの小さなDSLに、パーサージェネレータは大げさすぎる。パーサーコンビネータなら、アプリケーションと同じ言語で動作するパーサーを、生成コードもビルドステップもなしに構築できる。</description><pubDate>Tue, 30 Jun 2026 00:00:00 GMT</pubDate></item><item><title>ランタイムの設定エラーは、あなたが許容した本番環境の障害である</title><link>https://autotomy.dev/ja/blog/config-validation-build-time/</link><guid isPermaLink="true">https://autotomy.dev/ja/blog/config-validation-build-time/</guid><description>スキーマ検証とビルド時チェックを用いて、アプリケーションがトラフィックを処理し始める前に設定ミスを捕捉する方法。</description><pubDate>Mon, 29 Jun 2026 00:00:00 GMT</pubDate></item><item><title>依存関係は環境変数を読める。JavaScriptはそれを許している</title><link>https://autotomy.dev/ja/blog/javascript-capability-security-lockdown/</link><guid isPermaLink="true">https://autotomy.dev/ja/blog/javascript-capability-security-lockdown/</guid><description>Ambient Authorityとは、Node.jsプロセス内のあらゆるコードがファイルシステム、ネットワーク、環境に触れられる状態のことだ。ここでは、lockdown、compartment、明示的なcapabilityの受け渡しによってそれを剥ぎ取る方法を解説する。</description><pubDate>Sun, 28 Jun 2026 00:00:00 GMT</pubDate></item><item><title>ネットワークの近接性はアイデンティティではない：サービスが環境的権限なしに認証する方法</title><link>https://autotomy.dev/ja/blog/service-authentication-without-ambient-authority/</link><guid isPermaLink="true">https://autotomy.dev/ja/blog/service-authentication-without-ambient-authority/</guid><description>サービス間の信頼の大半は暗号学的証明ではなく、ネットワーク上の位置関係に基づいている。以下では、ケイパビリティ、相互TLS、SPIFFEを使ってサービスが環境的権限なしに認証する方法と、その実現が予想以上に難しい理由を解説する。</description><pubDate>Sat, 27 Jun 2026 00:00:00 GMT</pubDate></item><item><title>依存ライブラリがディスク上の任意のファイルを読める。cap-std は許可を求めさせる</title><link>https://autotomy.dev/ja/blog/rust-cap-std-capability-filesystem/</link><guid isPermaLink="true">https://autotomy.dev/ja/blog/rust-cap-std-capability-filesystem/</guid><description>Rust の標準ライブラリはあらゆる依存ライブラリに対して、暗黙的なファイルシステム権限を付与する。cap-std はそれを能力ベースの API に置き換え、コードがパスを開く前にそのアクセス権を証明することを強制する。</description><pubDate>Fri, 26 Jun 2026 00:00:00 GMT</pubDate></item><item><title>あなたのサービスは知らぬ間の共犯者：Confused Deputy Attackの仕組み</title><link>https://autotomy.dev/ja/blog/whats-a-confused-deputy-attack-and-how-do-i-prevent-it/</link><guid isPermaLink="true">https://autotomy.dev/ja/blog/whats-a-confused-deputy-attack-and-how-do-i-prevent-it/</guid><description>Confused Deputy Attackは、特権を持つサービスを騙してその権限を悪用させる攻撃です。ここでは、攻撃者が暗黙の信頼をどう突くか、そしてcapability-based securityがなぜ解決策になるかを解説します。</description><pubDate>Thu, 25 Jun 2026 00:00:00 GMT</pubDate></item><item><title>あなたの権限チェックは嘘をついている</title><link>https://autotomy.dev/ja/blog/typescript-capability-based-security/</link><guid isPermaLink="true">https://autotomy.dev/ja/blog/typescript-capability-based-security/</guid><description>ケイパビリティベースセキュリティは、散在するロールチェックを改ざん不可能な権限トークンで置き換える。コードを読みにくくすることなく TypeScript で実装する方法はこちら。</description><pubDate>Wed, 24 Jun 2026 00:00:00 GMT</pubDate></item><item><title>もしすべての関数が、権限を前提とするのではなく受け取る必要があったら？</title><link>https://autotomy.dev/ja/blog/capability-based-security-permissions/</link><guid isPermaLink="true">https://autotomy.dev/ja/blog/capability-based-security-permissions/</guid><description>ほとんどのコードは ambient authority のもとで動作している。つまり、すべての関数があらゆるリソースに暗黙的にアクセスできる。capability-based security はこのモデルを覆し、関数に明示的でスコープ化された権限を受け取らせる。</description><pubDate>Tue, 23 Jun 2026 00:00:00 GMT</pubDate></item><item><title>throw するのをやめて、エラーを返すべきか</title><link>https://autotomy.dev/ja/blog/should-i-stop-throwing-errors-and-start-returning-them/</link><guid isPermaLink="true">https://autotomy.dev/ja/blog/should-i-stop-throwing-errors-and-start-returning-them/</guid><description>例外を投げると、型システムから失敗の経路が見えなくなる。明示的なエラー返却がコードをより正直にする理由と、それを苦痛なく導入する方法。</description><pubDate>Mon, 22 Jun 2026 00:00:00 GMT</pubDate></item><item><title>Rustのnewtypeで、誤った状態をコンパイル時に無償で表現不能にする</title><link>https://autotomy.dev/ja/blog/rust-newtypes-zero-cost-safety/</link><guid isPermaLink="true">https://autotomy.dev/ja/blog/rust-newtypes-zero-cost-safety/</guid><description>1フィールドのラッパー構造体が、1バイトのオーバーヘッドも増やさずに単位混在バグや型の混同を防ぐ。</description><pubDate>Sun, 21 Jun 2026 00:00:00 GMT</pubDate></item><item><title>Switch文はコンパイル時にバグを見逃す</title><link>https://autotomy.dev/ja/blog/is-there-a-better-way-than-switch-statements-for-type-safe-matching/</link><guid isPermaLink="true">https://autotomy.dev/ja/blog/is-there-a-better-way-than-switch-statements-for-type-safe-matching/</guid><description>TypeScriptのswitch文は、ケースの欠落を黙って許してしまう。以下は、実行時ではなくビルド時に失敗する、網羅性チェック付きのパターンで置き換える方法だ。</description><pubDate>Sat, 20 Jun 2026 00:00:00 GMT</pubDate></item><item><title>コンパイラが不足している状態のケースを捕捉すべきだ。QAチームが見つけるのではなく</title><link>https://autotomy.dev/ja/blog/typescript-exhaustiveness-state-machines/</link><guid isPermaLink="true">https://autotomy.dev/ja/blog/typescript-exhaustiveness-state-machines/</guid><description>マシンに新しい状態を追加するのは簡単だ。すべてのswitch文を更新することを覚えておくのは難しい。TypeScriptに、ケースを忘れたときにコンパイルを拒否させる方法を紹介する。</description><pubDate>Fri, 19 Jun 2026 00:00:00 GMT</pubDate></item><item><title>はい、でも型システムにはドルが何かを教える必要がある</title><link>https://autotomy.dev/ja/blog/typescript-currency-types/</link><guid isPermaLink="true">https://autotomy.dev/ja/blog/typescript-currency-types/</guid><description>TypeScriptはすべての数値を同一に見なす。ここでは、コンパイラが本番環境に到達する前に通貨換算のバグを捕捉できるよう、USDとEURの違いを教える方法を紹介する。</description><pubDate>Thu, 18 Jun 2026 00:00:00 GMT</pubDate></item><item><title>数値はただの数値ではない：コンパイラに単位のバグを見つけさせる方法</title><link>https://autotomy.dev/ja/blog/typescript-unit-types-compile-time/</link><guid isPermaLink="true">https://autotomy.dev/ja/blog/typescript-unit-types-compile-time/</guid><description>ミリ秒を要求される場所に秒を渡すようなバグは、どんなテストも通り抜けてしまう。ここでは、単位を TypeScript の型システムに直接エンコードして、実行時コストゼロで混在をコンパイル時に検出する方法を解説する。</description><pubDate>Wed, 17 Jun 2026 00:00:00 GMT</pubDate></item><item><title>TypeScript が order ID が必要な場所に user ID を通してしまった</title><link>https://autotomy.dev/ja/blog/typescript-branded-types-newtypes/</link><guid isPermaLink="true">https://autotomy.dev/ja/blog/typescript-branded-types-newtypes/</guid><description>TypeScript の型エイリアスは区別された型を作らない。ブランド型は作る。コンパイル時に識別子を混同するのを防いでくれる。</description><pubDate>Tue, 16 Jun 2026 00:00:00 GMT</pubDate></item><item><title>Differential Testingは形式的証明なしで機能するが、Common-Mode Failureが落とし穴だ</title><link>https://autotomy.dev/ja/blog/differential-testing-common-mode-failures/</link><guid isPermaLink="true">https://autotomy.dev/ja/blog/differential-testing-common-mode-failures/</guid><description>Differential testingを使えば、正解を知らなくてもバグを見つけられる。問題は、相関した誤りが合意に見えることだ。盲点を見つける方法は以下の通り。</description><pubDate>Mon, 15 Jun 2026 00:00:00 GMT</pubDate></item><item><title>テストでは2つの関数が等価であることは証明できない。では何ができるのか。</title><link>https://autotomy.dev/ja/blog/function-equivalence-smt-solvers/</link><guid isPermaLink="true">https://autotomy.dev/ja/blog/function-equivalence-smt-solvers/</guid><description>N-version programmingは実装が一致することを前提とする。テストがなぜ不十分なのか、SMT solverがいかにして等価性を実際に証明できるのか、そして「十分に良い」と「形式的に検証済み」の境界線をどこに引くべきかを見ていく。</description><pubDate>Sun, 14 Jun 2026 00:00:00 GMT</pubDate></item><item><title>LLMの複数バリアントが異なる結果を出したら？どちらが正しい？</title><link>https://autotomy.dev/ja/blog/llm-variant-disagreement-resolution/</link><guid isPermaLink="true">https://autotomy.dev/ja/blog/llm-variant-disagreement-resolution/</guid><description>複数のLLMを並列実行すると、どの単一モデルも見逃すエラーを捕捉できる。実際に機能する不一致解決システムの構築方法を解説する。</description><pubDate>Sat, 13 Jun 2026 00:00:00 GMT</pubDate></item><item><title>5つの実装と多数派なし：実際に最良のものを選ぶ方法</title><link>https://autotomy.dev/ja/blog/n-version-implementation-selection/</link><guid isPermaLink="true">https://autotomy.dev/ja/blog/n-version-implementation-selection/</guid><description>N-version programmingは単純に聞こえる。複数の実装を実行して最良の答えを選ぶ。しかし実際には、「最良」を定義することは「最も一般的」を定義するよりはるかに難しい。</description><pubDate>Fri, 12 Jun 2026 00:00:00 GMT</pubDate></item><item><title>同じLLMで関数を5通りに書ける。本当に異なる実装を引き出す方法。</title><link>https://autotomy.dev/ja/blog/llm-n-version-diverse-implementations/</link><guid isPermaLink="true">https://autotomy.dev/ja/blog/llm-n-version-diverse-implementations/</guid><description>LLMによるN-version programmingに複数のモデルは不要。プロンプト、ペルソナ、推論の制約を変えることで、単一モデルから多様で正しい実装を引き出せる。</description><pubDate>Thu, 11 Jun 2026 00:00:00 GMT</pubDate></item><item><title>NASAは同じプログラムを27個並列実行した。バグは票を固めて投票した。</title><link>https://autotomy.dev/ja/blog/nasa-n-version-programming-knight-leveson/</link><guid isPermaLink="true">https://autotomy.dev/ja/blog/nasa-n-version-programming-knight-leveson/</guid><description>N-version programmingは、独立したチームが独立したミスをすると約束した。KnightとLevesonの1986年の実験はその逆を証明し、NASAは静かに撤退した。</description><pubDate>Wed, 10 Jun 2026 00:00:00 GMT</pubDate></item><item><title>Cucumberのシナリオの半分がスキップされている。そのステータスがあなたに嘘をついている理由。</title><link>https://autotomy.dev/ja/blog/cucumber-skipped-scenarios-diagnosis/</link><guid isPermaLink="true">https://autotomy.dev/ja/blog/cucumber-skipped-scenarios-diagnosis/</guid><description>Cucumberの「skipped」ステータスには、全く異なる3つの問題が隠れている。テストスイートを蝕んでいるのがどれか診断し、それを止める方法を解説する。</description><pubDate>Tue, 09 Jun 2026 00:00:00 GMT</pubDate></item><item><title>Gherkin仕様があなたに嘘をついている</title><link>https://autotomy.dev/ja/blog/gherkin-specs-automated-sync/</link><guid isPermaLink="true">https://autotomy.dev/ja/blog/gherkin-specs-automated-sync/</guid><description>Gherkin仕様は、人間に手動更新を任せた瞬間から乖離し始める。featureファイルを正直に保つための自動検証の方法を紹介する。</description><pubDate>Mon, 08 Jun 2026 00:00:00 GMT</pubDate></item><item><title>コンパイラは構文をチェックする。テストはアーキテクチャをチェックすべきだ。</title><link>https://autotomy.dev/ja/blog/architecture-tests-ci-enforcement/</link><guid isPermaLink="true">https://autotomy.dev/ja/blog/architecture-tests-ci-enforcement/</guid><description>多くのチームはアーキテクチャルールをWikiに記載している。依存グラフが逸脱した時にCIを失敗させる実行可能なテストとして書く方法を紹介する。</description><pubDate>Sun, 07 Jun 2026 00:00:00 GMT</pubDate></item><item><title>ドメイン層がPostgresをimportする。CIは何も言わない。</title><link>https://autotomy.dev/ja/blog/clean-architecture-domain-infrastructure-ci/</link><guid isPermaLink="true">https://autotomy.dev/ja/blog/clean-architecture-domain-infrastructure-ci/</guid><description>クリーンアーキテクチャの図はホワイトボード上では美しい。ここでは、ビルドパイプラインが依存方向を強制し、ドメインコードがインフラストラクチャに到達できないようにする方法を紹介する。</description><pubDate>Sat, 06 Jun 2026 00:00:00 GMT</pubDate></item><item><title>あなたのアーキテクチャ図は、すでに嘘になっている</title><link>https://autotomy.dev/ja/blog/architecture-docs-code-generated-diagrams/</link><guid isPermaLink="true">https://autotomy.dev/ja/blog/architecture-docs-code-generated-diagrams/</guid><description>アーキテクチャ資料は、保存した瞬間から陳腐化する。コード生成ダイアグラム、ADR、自動化されたアーキテクチャテストを使って、資料を正直な状態に保つ方法を解説する。</description><pubDate>Fri, 05 Jun 2026 00:00:00 GMT</pubDate></item><item><title>あなたのリトライループは最初のリクエストが失敗したと仮定している。実際にはそうではない可能性が高い。</title><link>https://autotomy.dev/ja/blog/idempotency-keys-api-retries/</link><guid isPermaLink="true">https://autotomy.dev/ja/blog/idempotency-keys-api-retries/</guid><description>タイムアウトやクラッシュは、APIリクエストが消失したことを意味しない。idempotency keyがどうやってリトライを安全にするか、そして実際に重複を防ぐストレージパターンについて解説する。</description><pubDate>Thu, 04 Jun 2026 00:00:00 GMT</pubDate></item><item><title>プロセスより長生きするロック：分散リースが実際にどう機能するのか</title><link>https://autotomy.dev/ja/blog/distributed-leases-fencing-tokens/</link><guid isPermaLink="true">https://autotomy.dev/ja/blog/distributed-leases-fencing-tokens/</guid><description>インメモリのミューテックスはサーバー再起動時に消滅する。フェンシングトークンとTTLを持つ分散リースが、クラッシュを跨いだ重複作業をどう防ぐか、そしてどこで破綻するかを解説する。</description><pubDate>Wed, 03 Jun 2026 00:00:00 GMT</pubDate></item><item><title>ゴルーチンもタイマーもバックグラウンドオーバーヘッドもないサーキットブレーカー</title><link>https://autotomy.dev/ja/blog/circuit-breaker-lazy-recovery-no-goroutines/</link><guid isPermaLink="true">https://autotomy.dev/ja/blog/circuit-breaker-lazy-recovery-no-goroutines/</guid><description>ほとんどのサーキットブレーカーライブラリは、復旧を検知するためにバックグラウンドスレッドを起動する。それは不要だ。ここでは、正確性を損なうことなくすべてのバックグラウンドオーバーヘッドを排除する、リクエスト駆動型の設計を紹介する。</description><pubDate>Tue, 02 Jun 2026 00:00:00 GMT</pubDate></item><item><title>Webサービスにグレースフルシャットダウンがある。それがバグだ。</title><link>https://autotomy.dev/ja/blog/crash-only-software-web-services/</link><guid isPermaLink="true">https://autotomy.dev/ja/blog/crash-only-software-web-services/</guid><description>クラッシュオンリーソフトウェアは、あらゆる障害をクラッシュとして扱い、あらゆる起動をリカバリーとして扱う。Webサービスにとってこれは、シャットダウンロジックを削除し、kill -9でも生き残る状態を設計することを意味する。</description><pubDate>Mon, 01 Jun 2026 00:00:00 GMT</pubDate></item><item><title>変化内容がわからない生存ミュータントを倒す方法</title><link>https://autotomy.dev/ja/blog/killing-surviving-mutants/</link><guid isPermaLink="true">https://autotomy.dev/ja/blog/killing-surviving-mutants/</guid><description>ミューテーションテストで生存者が見つかったが、そのミューテーションが何をしているのかまったくわからない。ミュータントを理解せずに正しいテストを書くためのステップバイステップの方法を紹介する。</description><pubDate>Sun, 31 May 2026 00:00:00 GMT</pubDate></item><item><title>認証コードには90%のmutation coverageが必要だ。文字列ユーティリティには不要。</title><link>https://autotomy.dev/ja/blog/mutation-score-per-module-risk/</link><guid isPermaLink="true">https://autotomy.dev/ja/blog/mutation-score-per-module-risk/</guid><description>コードベース全体に単一のmutation scoreを課すのが間違いである理由と、実際のリスクに応じたモジュールごとのthresholdの設定方法。</description><pubDate>Sat, 30 May 2026 00:00:00 GMT</pubDate></item><item><title>テストは通る。ミューテーションスコアは40%。生存ミュータントが実際に語っていること</title><link>https://autotomy.dev/ja/blog/my-tests-pass-but-my-mutation-score-is-40-whats-a-surviving-mutant/</link><guid isPermaLink="true">https://autotomy.dev/ja/blog/my-tests-pass-but-my-mutation-score-is-40-whats-a-surviving-mutant/</guid><description>コードカバレッジは安全だと言う。ミューテーションテストは、テストのほとんどが飾りだと言う。生存ミュータントがその差をどう晒し、どう埋めるか。</description><pubDate>Fri, 29 May 2026 00:00:00 GMT</pubDate></item><item><title>RustでMutation Testingは機能する——ただしコンパイル時間が悲鳴を上げる</title><link>https://autotomy.dev/ja/blog/rust-mutation-testing-cargo-mutants/</link><guid isPermaLink="true">https://autotomy.dev/ja/blog/rust-mutation-testing-cargo-mutants/</guid><description>cargo-mutantsは、コードを検証したふりをしているテストを見つけ出す。Rustでのmutation testingの仕組み、何が捉えられるのか、そしてコンパイル時間のコストに見合う価値があるかを解説する。</description><pubDate>Thu, 28 May 2026 00:00:00 GMT</pubDate></item><item><title>検証スペクトラム：AIコーディングがバックエンドで最も効果的な理由</title><link>https://autotomy.dev/ja/blog/ai-coding-validation-spectrum-backend-web-mobile/</link><guid isPermaLink="true">https://autotomy.dev/ja/blog/ai-coding-validation-spectrum-backend-web-mobile/</guid><description>AIコーディングは検証の勾配に従う。バックエンドはミリ秒で検証し、Webは数分、モバイルは数時間かかる。フィードバックループがAIコーディングの有効範囲を決める。</description><pubDate>Wed, 27 May 2026 00:00:00 GMT</pubDate></item><item><title>猿と機関銃とaimbot：コーディングチームのためのAIガバナンス</title><link>https://autotomy.dev/ja/blog/monkey-machine-gun-aimbot/</link><guid isPermaLink="true">https://autotomy.dev/ja/blog/monkey-machine-gun-aimbot/</guid><description>AIコードガバナンスとは、ジュニア開発者やAIエージェントからツールを取り上げることではない。すべての弾丸を標的に命中させ、巻き添え被害を出さないguardrailsを導入することだ。</description><pubDate>Wed, 27 May 2026 00:00:00 GMT</pubDate></item><item><title>ミューテーションテストに4時間かかる。ではチームは実際にCIでどう使っているのか？</title><link>https://autotomy.dev/ja/blog/mutation-testing-takes-4-hours-how-do-teams-actually-use-it-in-ci/</link><guid isPermaLink="true">https://autotomy.dev/ja/blog/mutation-testing-takes-4-hours-how-do-teams-actually-use-it-in-ci/</guid><description>ほとんどのチームはすべてのコミットでフルのミューテーションテストスイートを実行していない。ここでは、ビルドパイプラインを破壊することなく、エンジニアリングチームが実際にミューテーションテストをCIに統合する方法を紹介する。</description><pubDate>Wed, 27 May 2026 00:00:00 GMT</pubDate></item><item><title>ユニットテストは通るのに、データは消えている</title><link>https://autotomy.dev/ja/blog/database-persistence-testing-mocks/</link><guid isPermaLink="true">https://autotomy.dev/ja/blog/database-persistence-testing-mocks/</guid><description>モック化されたデータベースのテストはSQLの構文を検証するだけで、クラッシュや並列書き込み、スキーマの不整合を経ても行が存続するかどうかは検証しない。永続性を本気でテストする方法を紹介する。</description><pubDate>Tue, 26 May 2026 00:00:00 GMT</pubDate></item><item><title>恐怖か驀進か：AIコーディングが分ける二つの現実</title><link>https://autotomy.dev/ja/blog/fear-vs-steamroll-ai-coding-divide/</link><guid isPermaLink="true">https://autotomy.dev/ja/blog/fear-vs-steamroll-ai-coding-divide/</guid><description>AIコーディングが機能するのは、どんな混乱からも立ち直れるエリートチームだけ。それ以外に残るのは恐怖とCI失敗と放棄された実験。格差の本質はモデルではない。</description><pubDate>Tue, 26 May 2026 00:00:00 GMT</pubDate></item><item><title>モックアクションだらけにならずにReduxをテストする</title><link>https://autotomy.dev/ja/blog/redux-testing-real-state-transitions/</link><guid isPermaLink="true">https://autotomy.dev/ja/blog/redux-testing-real-state-transitions/</guid><description>すべてのReduxアクションをモックすると、テストは変更履歴の検証ツールになってしまう。実際の状態遷移を使ってストアをテストする方法を紹介する。</description><pubDate>Mon, 25 May 2026 00:00:00 GMT</pubDate></item><item><title>本番環境でのAIコーディング：ほとんどのチームが挫折する理由</title><link>https://autotomy.dev/ja/blog/ai-coding-in-production-autotomy-framework/</link><guid isPermaLink="true">https://autotomy.dev/ja/blog/ai-coding-in-production-autotomy-framework/</guid><description>ほとんどのチームはAIコーディングを試し、QAに不合格になるコードをリリースし、そして諦める。問題はモデルではない——AIの出力を信頼できるものにするガードレールの欠如だ。</description><pubDate>Sun, 24 May 2026 00:00:00 GMT</pubDate></item><item><title>100 Test Runs Is a Lie: Property-Based Testを実際にどうサイジングすべきか</title><link>https://autotomy.dev/ja/blog/property-based-testing-run-count/</link><guid isPermaLink="true">https://autotomy.dev/ja/blog/property-based-testing-run-count/</guid><description>Property-based testingのデフォルト100例は統計的戦略ではなく社会的妥協だ。自分の信頼性の要件とCI予算にマッチする実行回数の選び方を解説する。</description><pubDate>Sun, 24 May 2026 00:00:00 GMT</pubDate></item><item><title>Fuck-u-code: AIパイプラインが見落としていた Deterministic 品質ゲート</title><link>https://autotomy.dev/ja/blog/fuck-u-code-deterministic-quality-gate-ai-pipeline/</link><guid isPermaLink="true">https://autotomy.dev/ja/blog/fuck-u-code-deterministic-quality-gate-ai-pipeline/</guid><description>型チェック、lint、設計ルールはある。でも deterministic スタックは複雑性、重複、命名の惨状を見抜けない。$0で解決する方法を紹介する。</description><pubDate>Sat, 23 May 2026 00:00:00 GMT</pubDate></item><item><title>Rustのプロパティベーステストが単体テストでは見逃すバグを見つける</title><link>https://autotomy.dev/ja/blog/rust-property-based-testing-quickcheck/</link><guid isPermaLink="true">https://autotomy.dev/ja/blog/rust-property-based-testing-quickcheck/</guid><description>例ベースのテストは思いついた入力だけをカバーする。プロパティベースのテストはランダムデータを生成し、不変条件を検証し、失敗を最小の反例まで縮小する。</description><pubDate>Sat, 23 May 2026 00:00:00 GMT</pubDate></item><item><title>バージョン1は決して問題ではない：AIコーディングと長期保守</title><link>https://autotomy.dev/ja/blog/ai-coding-why-version-one-is-never-the-problem/</link><guid isPermaLink="true">https://autotomy.dev/ja/blog/ai-coding-why-version-one-is-never-the-problem/</guid><description>AIコーディングツールはバージョン1の生成に優れている。本当のエンジニアリング上の課題はバージョン4から始まる — チームが他のすべてを壊さずに何かを変更する必要が出たときだ。</description><pubDate>Fri, 22 May 2026 00:00:00 GMT</pubDate></item><item><title>AI生成コードと置換可能性の原則</title><link>https://autotomy.dev/ja/blog/ai-generated-code-replaceability-principle/</link><guid isPermaLink="true">https://autotomy.dev/ja/blog/ai-generated-code-replaceability-principle/</guid><description>AI生成コードの品質を測る真の基準は、初日に動くかどうかではない。30日目に他のすべてをrewriteせずにそのコードを置換できるかどうかだ。</description><pubDate>Fri, 22 May 2026 00:00:00 GMT</pubDate></item><item><title>AI Codebaseのための決定的ガードレール</title><link>https://autotomy.dev/ja/blog/deterministic-guardrails-ai-codebases/</link><guid isPermaLink="true">https://autotomy.dev/ja/blog/deterministic-guardrails-ai-codebases/</guid><description>人間のレビューは一貫性がない。AIレビューはさらに悪い。AI生成codebaseに対するスケーラブルな唯一の防御は決定的enforcement — 無視される提案ではなく、ビルドを失敗させるルールだ。</description><pubDate>Fri, 22 May 2026 00:00:00 GMT</pubDate></item><item><title>ユニットテストはパスする。本番コードは壊れたまま。</title><link>https://autotomy.dev/ja/blog/i-write-unit-tests-why-do-bugs-still-slip-through/</link><guid isPermaLink="true">https://autotomy.dev/ja/blog/i-write-unit-tests-why-do-bugs-still-slip-through/</guid><description>コードカバレッジのメトリックは偽の安心感を生む。ここでは、ユニットテストがなぜ実際に寝不足を引き起こすバグを見逃し、代わりに何をテストすべきかを解説する。</description><pubDate>Fri, 22 May 2026 00:00:00 GMT</pubDate></item><item><title>Rustのランタイムcontractsはリリースビルドで無料にできるが、コンパイラは勝手にやってくれない</title><link>https://autotomy.dev/ja/blog/rust-zero-cost-runtime-contracts/</link><guid isPermaLink="true">https://autotomy.dev/ja/blog/rust-zero-cost-runtime-contracts/</guid><description>Rustはdebug assertionsを自動で除去するが、本物のdesign-by-contractにはdebug_assert!以上のものが必要だ。リリースバイナリーから完全に消えるゼロコストのランタイムcontractsを作る方法を紹介する。</description><pubDate>Thu, 21 May 2026 00:00:00 GMT</pubDate></item><item><title>ゼロ、一、それとも十二：本番環境の関数に実際に必要なアサーションの数</title><link>https://autotomy.dev/ja/blog/production-assertion-decision-framework/</link><guid isPermaLink="true">https://autotomy.dev/ja/blog/production-assertion-decision-framework/</guid><description>開発者はアサーションを紙吹雪のように撒き散らすか、あるいは完全に避けるかのどちらかだ。有用な不変条件と本番クラッシュのトリガーを分ける判断フレームワークを紹介する。</description><pubDate>Wed, 20 May 2026 00:00:00 GMT</pubDate></item><item><title>バリデーション層がビジネスロジックより肥大化している</title><link>https://autotomy.dev/ja/blog/declarative-runtime-contracts-validation/</link><guid isPermaLink="true">https://autotomy.dev/ja/blog/declarative-runtime-contracts-validation/</guid><description>手作りのバリデーションは codebase を膨張させ、それでもエッジケースを見逃す。宣言的なスキーマで runtime contracts を enforce し、実装に干渉しない方法を解説する。</description><pubDate>Tue, 19 May 2026 00:00:00 GMT</pubDate></item><item><title>TypeScriptのstrictNullChecksはコンパイル時のガードであり、実行時の盾ではない</title><link>https://autotomy.dev/ja/blog/typescript-strictnullchecks-runtime-nulls/</link><guid isPermaLink="true">https://autotomy.dev/ja/blog/typescript-strictnullchecks-runtime-nulls/</guid><description>strict modeはあなたが書いたnullを捉えるが、APIやDOMクエリ、JSON.parseから実行時に到達するnullは捉えない。型システムが終わり、あなたの防御が始まる境界はここだ。</description><pubDate>Mon, 18 May 2026 00:00:00 GMT</pubDate></item><item><title>AI時代、コードレビューは仕様レビューになる</title><link>https://autotomy.dev/ja/blog/code-review-becomes-specification-review/</link><guid isPermaLink="true">https://autotomy.dev/ja/blog/code-review-becomes-specification-review/</guid><description>AI が仕様から実装、テスト、contracts まで生成できるようになると、人間が最も大きなレバレッジを発揮する仕事は上流へ移る。最も厳しく吟味すべきものは、仕様そのものだ。</description><pubDate>Sun, 17 May 2026 00:00:00 GMT</pubDate></item><item><title>AI Safety Stack: types、contracts、property tests、mutation gates</title><link>https://autotomy.dev/ja/blog/ai-safety-stack-types-contracts-property-tests-mutation/</link><guid isPermaLink="true">https://autotomy.dev/ja/blog/ai-safety-stack-types-contracts-property-tests-mutation/</guid><description>AI-generated code を production で持たせたいなら、code review だけでは足りません。type constraints から mutation testing、runtime containment までの layered safety stack が必要です。</description><pubDate>Sat, 16 May 2026 00:00:00 GMT</pubDate></item><item><title>メテオフォール型開発は本当にある。コードベースまで一緒に崩れる必要はない</title><link>https://autotomy.dev/ja/blog/meteor-development-is-real/</link><guid isPermaLink="true">https://autotomy.dev/ja/blog/meteor-development-is-real/</guid><description>この言葉が刺さるのは、チームが実際に動き続ける要件、固定の締切、半分しか固まっていない作業範囲の中で開発しているからです。Autotomy は幻想的な計画を直せませんが、開発を止めない構造は作れます。</description><pubDate>Sat, 16 May 2026 00:00:00 GMT</pubDate></item><item><title>Stanford CS146S は AI coding を正しく見ている。足りない科目はアーキテクチャだ</title><link>https://autotomy.dev/ja/blog/stanford-cs146s-ai-architecture-gap/</link><guid isPermaLink="true">https://autotomy.dev/ja/blog/stanford-cs146s-ai-architecture-gap/</guid><description>Stanford CS146S を AIアーキテクチャの観点からレビューし、AI coding への評価は正しい一方で、置き換え可能性を支える設計規律が欠けている点を批評します。</description><pubDate>Sat, 16 May 2026 00:00:00 GMT</pubDate></item><item><title>優れたエンジニアリングの考え方が AI で経済的になるまでニッチのままだった理由</title><link>https://autotomy.dev/ja/blog/engineering-ideas-ai-economics/</link><guid isPermaLink="true">https://autotomy.dev/ja/blog/engineering-ideas-ai-economics/</guid><description>Design by contract、property-based testing、mutation testing、model checking は悪い考え方だったわけではありません。継続運用に必要な専門知が重すぎただけです。AI はその前提を変えます。</description><pubDate>Fri, 15 May 2026 00:00:00 GMT</pubDate></item><item><title>なぜ AI 生成コードにはガードレールが必要なのか</title><link>https://autotomy.dev/ja/blog/ai-react-native-guardrails-scaling/</link><guid isPermaLink="true">https://autotomy.dev/ja/blog/ai-react-native-guardrails-scaling/</guid><description>AI なら React Native MVP をすばやく ship できるが、guardrails がなければ小さな変更ひとつで無関係な flow まで壊れる。速度を fragility に変えないための declarative constraints を説明します。</description><pubDate>Thu, 14 May 2026 00:00:00 GMT</pubDate></item><item><title>Vibe coder のための React Native App Lifecycle ガイド</title><link>https://autotomy.dev/ja/blog/app-lifecycle-resume-status/</link><guid isPermaLink="true">https://autotomy.dev/ja/blog/app-lifecycle-resume-status/</guid><description>dev では問題ないのに、昼休みのあと戻ると白画面になる。ネイティブの lifecycle を正しく扱う resume status パターンを説明します。</description><pubDate>Thu, 14 May 2026 00:00:00 GMT</pubDate></item><item><title>なぜ Vibe-coded React Native app は起動時に落ちるのか</title><link>https://autotomy.dev/ja/blog/dependency-tiers-hard-soft-optional/</link><guid isPermaLink="true">https://autotomy.dev/ja/blog/dependency-tiers-hard-soft-optional/</guid><description>optional SDK が core infrastructure と同じように初期化されると、app は起動直後に crash する。non-critical な tool が production を巻き込まないための dependency tier system を説明します。</description><pubDate>Thu, 14 May 2026 00:00:00 GMT</pubDate></item><item><title>なぜ Cursor + NativeWind の Vibe coding はスケール時に壊れるのか</title><link>https://autotomy.dev/ja/blog/nativewind-vs-stylesheet-contract/</link><guid isPermaLink="true">https://autotomy.dev/ja/blog/nativewind-vs-stylesheet-contract/</guid><description>Cursor で週末に MVP を出したのに、brand color を 1 つ変えるだけで 47 ファイルに find-and-replace が必要になる。出血を止める styling contract を説明します。</description><pubDate>Thu, 14 May 2026 00:00:00 GMT</pubDate></item><item><title>なぜ Claude Code にコードレビューを任せるべきではないのか（代わりに何を使うべきか）</title><link>https://autotomy.dev/ja/blog/o1-guards-vs-llm-reviews/</link><guid isPermaLink="true">https://autotomy.dev/ja/blog/o1-guards-vs-llm-reviews/</guid><description>LLM コードレビューは非決定的で遅く、アーキテクチャ違反を見逃す。コードを本当にクリーンに保つ O(1) ガードスタックを紹介します。</description><pubDate>Thu, 14 May 2026 00:00:00 GMT</pubDate></item><item><title>置き換えでリファクタするという新しい考え方</title><link>https://autotomy.dev/ja/blog/refactor-by-replacement/</link><guid isPermaLink="true">https://autotomy.dev/ja/blog/refactor-by-replacement/</guid><description>既存コードを守る発想をやめ、削除前提で設計する。Autotomy パターンがモジュールを安全に差し替えられる理由を説明します。</description><pubDate>Thu, 14 May 2026 00:00:00 GMT</pubDate></item><item><title>React Native の service boundaries と composition root</title><link>https://autotomy.dev/ja/blog/service-boundaries-composition-root/</link><guid isPermaLink="true">https://autotomy.dev/ja/blog/service-boundaries-composition-root/</guid><description>React Native の画面から外部 SDK への依存を切り離すには。service boundaries、interface、composition root を使い、AI が変更する範囲を明確にします。</description><pubDate>Thu, 14 May 2026 00:00:00 GMT</pubDate></item><item><title>なぜ deep link は Vibe-coded React Native app を crash させるのか</title><link>https://autotomy.dev/ja/blog/url-validation-expo-router/</link><guid isPermaLink="true">https://autotomy.dev/ja/blog/url-validation-expo-router/</guid><description>deep link、push payload、shared URL はすべて untrusted input です。壊れた param が screen に届く前に、Expo Router boundary で validate する方法を説明します。</description><pubDate>Thu, 14 May 2026 00:00:00 GMT</pubDate></item><item><title>useSyncExternalStore: Vibe-coded app を state バグから守る React Hook</title><link>https://autotomy.dev/ja/blog/useSyncExternalStore-pattern/</link><guid isPermaLink="true">https://autotomy.dev/ja/blog/useSyncExternalStore-pattern/</guid><description>memory leak したり state update を取りこぼしたりする useEffect subscription はもうやめる。bulletproof な external state のための React 18 pattern を説明します。</description><pubDate>Thu, 14 May 2026 00:00:00 GMT</pubDate></item></channel></rss>