2026/02/22 9:29

Claude コードの使い方：計画と実行の分離

RSS: https://news.ycombinator.com/rss

元のHacker News記事へ ↗

要約▶

日本語訳：

記事は約9か月の経験に基づくClaude Codeを使用するための規律あるワークフローを提示しています。研究、計画、および実行を分離し、各フェーズが進む前に承認済みのマークダウンアーティファクトを生成することを強調しています。

リサーチ (research.md) – Claude は対象フォルダーを徹底的にスキャンし、ユーザーが検証しなければならない詳細レポートを作成します。表面的な読み込みは推奨されません。
計画 (plan.md) – コードスニペット、ファイルパス、トレードオフ、および説明を含む別のマークダウン計画が用意されます。組み込みのプランモードは拒否され、この編集可能なドキュメントが採用されます。
注釈サイクル – ユーザーはエディタで計画をレビューし、インラインメモや制約を追加して「まだ実装しない」ガード付きで再送します。このサイクルは計画が完全に受理されるまで繰り返されます。
実行 – 実装前に詳細なTODOリストが計画に追加されます。その後、著者は固定プロンプト「implement it all…」を発行し、Claude にすべてを実行させ、計画内の完了状況を更新させ、不必要なコメントや未知のタイプを避け、型チェックを継続的に実行させます。
修正 – 実行中にユーザーは簡潔な修正（多くの場合単一文）を提供します。フロントエンドでの修正にはスクリーンショットや既存パターンへの参照が含まれる場合があります。
制御と永続性 – 著者はアーキテクチャ的なコントロールを決して手放しません。Claude の提案を評価し、必要に応じて変更またはスキップします。3つのフェーズすべてが単一の長時間セッションで行われ、計画ファイルは自動圧縮を通じて保持され、主要な参照として機能します。

マークダウンファイルを共有可変状態として維持することで、このアプローチはノイズの多いチャットインタラクションを減らし、追跡性を向上させ、大規模プロジェクト全体で一貫したインターフェースを保ちます。

本文

私は Claude Code を主な開発ツールとして使い始めて約 9 ヶ月が経ちました。私が確立したワークフローは、AI コーディングツールを利用するほとんどの人々とは根本的に異なります。

ほとんどの開発者は「プロンプトを入力し、時にはプランモードを使い、エラーを修正して繰り返す」だけです。より「ターミナル志向」の人たちは、ラルフ・ループや MCP（マイクロサービス・チェーン）、ガストウンズ（当時流行っていたもの？）などを組み合わせて作業します。どちらの方法も、非 trivial な何かに取り掛かると散らかったまま崩れてしまいます。

コア原則

Claude にコードを書かせる前に、必ず書面で計画をレビューして承認してください。

プランニングと実行の分離は、私が最も重視することです。これによって無駄な労力を防ぎ、アーキテクチャ決定をコントロールし、コードに直接飛び込むよりもトークン使用量を抑えつつ大幅に良い結果を得られます。

フローチャート

flowchart LR
    R[リサーチ] --> P[プラン]
    P --> A[アノテーション]
    A -->|1〜6回繰り返し| A
    A --> T[TODO リスト]
    T --> I[実装]
    I --> F[フィードバック & 反復]

フェーズ 1：リサーチ

すべての有意義なタスクは、深く読み込む指示から始まります。
Claude にコードベースの該当部分を徹底的に理解させるよう求めます。そして、発見内容は必ず Markdown ファイルに書き留めさせます―チャットで口頭要約するだけではありません。

例：

「このフォルダを深く読み込み、仕組みや機能、すべての特異性を理解してください。完了したら、
```
research.md
```
に詳細レポートを書いてください。」
「通知システムを詳しく調査し、その細部まで把握して、通知がどのように動作するかをすべて含むリサーチ文書を作成してください。」
「タスクスケジューリングフローを確認し、潜在的なバグを探します。確実にバグは存在します。バグがすべて見つかるまで調査を続けてください。完了したら、
```
research.md
```
に詳細レポートを書いてください。」

言葉遣いが重要です。「深く」「細部まで」「複雑さ」「すべてを通じて」などの語句が無いと Claude はざっくり読んでしまいます。書面（

research.md

）は私のレビュー対象です。リサーチが誤っていると、プランも実装も誤ります。

フェーズ 2：プランニング

リサーチを確認したら、別 Markdown ファイルに詳細な実装計画を書かせます。

例：

「新機能
```
<name>
```
を作り、システムが
```
<ビジネスアウトカム>
```
を達成できるようにします。
```
plan.md
```
に実装方法を詳細に記述し、コードサンプルも含めてください。」
「リストエンドポイントはオフセットではなくカーソルベースのページングをサポートする必要があります。実現手段について詳細なプランを書いてください。変更提案前にソースファイルを読み込み、実際のコードベースに基づいた計画を立ててください。」

生成されるプランは必ず以下を含みます：

アプローチの詳細説明
実際の変更点を示すコードスニペット
変更対象ファイルパス
考慮事項とトレードオフ

私は Claude Code の組み込みプランモードではなく、独自に作成した

.md

プランファイルを使用します。これにより完全な制御が可能で、エディタで編集でき、実際の成果物として永続化されます。

アノテーションサイクル

これは私のワークフローで最も特徴的な部分です。ここで最大の価値を提供します。

flowchart TD
    W[Claude が plan.md を書く] --> R[I はエディタでレビュー]
    R --> N[I はインラインノートを追加]
    N --> S[Claude に文書へ戻すよう送信]
    S --> U[Claude がプランを更新]
    U --> D{満足？}
    D -->|いいえ| R
    D -->|はい| T[TODO リスト要求]

Claude が計画を書いたら、エディタで開いてインラインノートを直接文書に追加します。仮定の修正、アプローチの拒否、制約の追加、Claude が持っていないドメイン知識の提供などです。

例：

「
```
drizzle:generate
```
をマイグレーションに使用し、raw SQL は使わないでください」
「これは PATCH ではなく PUT にしてください」
「このセクションは完全に削除してください。キャッシュは不要です」
「キューコンシューマーはすでにリトライを処理しているので冗長なリトライロジックは削除してください」
「visibility フィールドはアイテム単位ではなく、リスト自体に設定する必要があります」

その後、Claude に「文書に数点のノートを追加しました。すべてのノートに対応し、文書を更新してください。ただしまだ実装は行わないでください」と指示します。

このサイクルは 1〜6 回繰り返されます。「まだ実装しない」という明確なガードが不可欠です。さもなくば Claude は計画が十分だと判断した瞬間にコードを書き始めてしまいます。

TODO リスト

実装を開始する前に、必ず詳細なタスク分解を要求します：

「プランにすべてのフェーズと個別タスクを含む詳細な todo リストを追加してください。まだ実装は行わないでください。」

これによりチェックリストが生成され、実装中の進捗管理に役立ちます。Claude はタスク完了時に項目をマークし、いつでもプランを見れば現状を確認できます。

フェーズ 3：実装

プランが整ったら、実装コマンドを発行します。このプロンプトはセッションを通じて再利用しています：

「すべて実装してください。タスクやフェーズごとに完了したらプランドキュメントにマークしてください。すべてのタスク・フェーズが完了するまで停止しないでください。不要なコメントや JSDoc は追加せず、
any
や未知の型は使わないでください。常に型チェックを実行して、新たな問題を導入していないか確認してください。」

この単一プロンプトにはすべてが詰まっています：

「すべて実装」 – 計画通り全作業を行う
「完了マーク」 – プランは進捗の真実源
「停止しない」 – 確認待ちで中断しない
「不要コメント禁止」 – コードをクリーンに保つ
「
```
any
```
禁止」 – 厳格な型付け維持
「常時型チェック」 – 問題を早期発見

「実装してください」と言うと、すべての決定は既に行われ検証済みです。実装は機械的であり、創造性はアノテーションサイクルに集中します。

実装中のフィードバック

Claude が計画を実行している間、私の役割は建築家から監督へとシフトします。プロンプトは短くなります。

flowchart LR
    I[Claude が実装] --> R[I はレビュー/テスト]
    R --> C{正しい？}
    C -->|いいえ| F[簡潔修正]
    F --> I
    C -->|はい| N{追加タスクはあるか？}
    N -->|はい| I
    N -->|いいえ| D[完了]

例：

「
```
deduplicateByTitle
```
関数を実装していませんでした」
「設定ページをメインアプリに作ったが、管理アプリであるべきです。移動してください」

ビジュアル上の問題にはスクリーンショットを添付したり、「もっと広く」「まだ切れている」「2px の隙間がある」といった最小限の変更点を説明します。既存コードを常に参照し：

「このテーブルはユーザー一覧と同じ見た目で、ヘッダー・ページネーション・行密度も同じにしてください。」

何か問題が発生したら Git の変更をリセットして再スコープします：

「すべて元に戻しました。今はリストビューだけをもっとミニマルにしたいです。他は何もしません」

コントロールを保つ

Claude に実行を委譲しても、何が構築されるかについて完全な自律権を与えることはありません。大部分の指示は

plan.md

で行います。

flowchart TD
    P[Claude が変更案を提案] --> E[I は各項目を評価]
    E --> A[そのまま受け入れる]
    E --> M[アプローチを修正]
    E --> S[スキップ/削除]
    E --> O[技術的選択を上書き]
    A & M & S & O --> R[実装範囲の最終調整]

提案から必要なものだけを抜粋し、スコープを絞り、既存インターフェースを保護し、必要に応じて技術選択を上書きします。Claude は機械的実行のみ担当し、判断は私が行います。

単一長時間セッション

リサーチ・プランニング・実装を別々のセッションで分けず、1 つの長いセッション内で完結させます。例えば、フォルダの深読みから始めて、3 回のアノテーションサイクルを経て、すべての実装を一連で行います。

コンテキストウィンドウが満杯になった場合、Claude の自動圧縮機能が必要な情報だけ残しつつ継続できるようにします。プラン文書は完全性を保ったまま保持されます。

ワークフローを一言で

深く読む → 計画を書く → それが正しいまでアノテーションする → Claude にすべて実行させ、型チェックを継続しながら進める。

これだけです。魔法のプロンプトや複雑なシステム指示、巧妙なハックは不要で、思考と入力を分離した厳格なパイプラインにすぎません。

同じ日のほかのニュース

一覧に戻る →

2026/02/22 9:21

**回答** 実際には、ほとんどの最新コンパイラは「決定的（deterministic）」です。同じソースコードと同一のコンパイルオプション（使用するコンパイラのバージョンや基盤となるプラットフォームを含む）を与えれば、何度実行しても同一のオブジェクトファイルまたはバイナリが生成されます。ただし、いくつか注意すべき点があります。 | 要因 | 決定性への影響 | |------|----------------| | **コンパイラ実装** | よく設計されたコンパイラは決定的ですが、不具合のあるものではそうでない場合もあります。 | | **ビルド環境** | OS、CPU アーキテクチャ、またはライブラリのバージョンが異なると、ソースコード自体に変更がなくても出力が変わることがあります。 | | **非決定的なパス** | 例としてランダム化されたレジスタ割り当てなど、一部の最適化は性能調査のために意図的にばらつきを導入します。 | | **タイムスタンプ／ビルドメタデータ** | バイナリにはしばしばタイムスタンプやビルド識別子が埋め込まれます。これを削除（例：GCC/Clang の `-Wl,--build-id=none`）すると、バイト単位で完全に同一の出力が得られます。 | したがって、環境を統制し安定したコンパイラリリースを使用すれば決定的な結果が期待できます。セキュリティや監査目的で確実な再現性が必要な場合は、**Reproducible Builds** のようなツールを使い、非決定的データを除去する手順を踏むと良いでしょう。

## Japanese Translation: 記事は、ソフトウェアビルドにおける真の決定論が実現しづらい理由を説明しています。入力状態のすべての部分―ソースコード、コンパイラフラグ、ツールチェーンバイナリ、環境変数、ファイルシステムレイアウト、ロケール、クロック、カーネル動作、さらにはハードウェア並列性までも―を完全に指定しなければ、「ノイズ」が出力の漂移を引き起こします。再現可能ビルドの実践は、ツールチェーンを凍結し、タイムスタンプを正規化（`SOURCE_DATE_EPOCH`）、揮発性メタデータを除去し、`-ffile-prefix-map` でパスを標準化し、ヘルミティックコンテナ内でビルドし、アーカイブを決定的に作成（`ar -D`）することでこれらの問題を緩和します。そうしても、GCC 18574 のようなバグが示すように、内部ポインタハッシュの不安定性は同一ソースから生成されるコードを変化させる可能性があります。コンパイラ契約はビット単位での同一性ではなく、セマンティクス（観測可能な I/O、揮発性アクセス、アトミック保証）の保持に焦点を当てています。不定動作がこの保証を弱めるため、再現可能ビルドはより厳格な要件となります。`__DATE__/__TIME__` のようなエントロピー源、デバッグ情報内の絶対パス、ロケール依存のソート（`LC_ALL`）、並列ビルドの競合順序、ランダムシード、ネットワークフェッチはすべて再現性を破る要因となり得ます。ASLR がコンパイラパスに間接的に影響することも同様です。歴史的には、2013 年以降の Debian の再現可能ビルド取り組みが、同一ソースから同一アーティファクトを作ることを主流化し、コンパイラ・リンカ・パッケージング・ビルドシステム全体で意図的な設計が必要であることを示しています。将来に向けて、記事は LLM で支援される開発チームが決定論的検証ゲート―制約付き入力、テスト可能な出力、再現性のある CI パイプライン―を導入して信頼できるデプロイを確保する必要があると主張しています。完全な決定論は必須ではありませんが、予測可能な振舞いと検証可能性は本番システムに不可欠です。主要な結論は、多くのエコシステムが多くの境界ケースで意図的な取り組みを通じて再現可能ビルドをサポートしているということですが、Ken Thompson の「Reflections on Trusting Trust」からの根本的な警告は残ります―コンパイラは信頼できるように見えても妥協され得るのです。

2026/02/22 5:57

**HN掲示：NVMe→GPU バイパスでCPUを経由せず、単一のRTX 3090上でLlama 3.1 70B を動作させる**

## Japanese Translation: **NTransformer** は、依存関係のない軽量 C++/CUDA エンジンであり、ユーザーが PCIe 上でモデル層をストリーミングし、オプションで高速直接 I/O 用に NVMe を使用することで、70 B 変種を含むフルサイズ Llama モデルをコンシューマ GPU 上で直接実行できるようにします。 - **Resident mode（レジデントモード）**：Llama 3.1‑8 B Q8_0 は 10 GB の VRAM だけで 48.9 トークン/秒を達成し、tiered‑auto モードは 10.3 GB を使用して 48.8 トークン/秒を提供します。 - **70 B model（70 B モデル）**：ストリーミング（mmap）のみでは非常に遅く (0.006 トークン/秒、7.3 GB)、tiered auto はスループットを 0.2 トークン/秒まで向上させ、23.1 GB を消費します。Q4_K_M のレイヤー・スキップを使用すると速度が 0.5 トークン/秒に上昇し、わずか 22.9 GB で済みます。これは単一 RTX 3090 + 48 GB RAM システムでのプレーン mmap に対して 83 倍速です。 - **Bandwidth bottleneck（帯域幅ボトルネック）**：PCIe Gen3 x8 (~6.5 GB/s) がデータ転送を制限します。Q4_K_M は VRAM に 10 層多く収容でき (36 層対 26 層)、tier‑B 転送が削減され、スループットが向上します。 - **Layer‑skip（レイヤー・スキップ）**：コサイン類似度キャリブレーションを使用して、1 トークンあたり 20–80 層を最小限の品質低下でスキップし、大規模モデルの推論速度を向上させます。 - **Architecture（アーキテクチャ）**：3 タイヤの適応型キャッシュが VRAM‑resident、ピン留め RAM、および NVMe/mmap タイヤを自動的にサイズ決定します。エンジンはすべての GGUF 量子化 (Q4_0, Q8_0, Q4_K_M, Q5_K, Q6_K, F16, F32) をサポートし、レジデント、tiered‑auto、layer‑skip、および self‑speculative decoding の 4 種類の自動選択データパスを提供します。 - **System requirements（システム要件）**：Linux (Ubuntu kernel 6.17+)、CUDA 13.1、gcc‑14/g++‑14、CMake 3.24+、NVIDIA GPU CC 8.0+ (RTX 3090 テスト済み)。直接 I/O 用に別の PCIe スロットに NVMe SSD が必要です。セットアップスクリプトはカーネルモジュールをパッチし、AMD IOMMU を無効化し、NVMe を VFIO にバインドします（DMA 分離について注意）。 - **NVMe‑direct pipeline（NVMe 直接パイプライン）**：各層 (~670 MB for 70 B Q6_K) は約 202 ms の NVMe コマンドで CUDA‑ピン留めステージングメモリに読み込まれ、非同期 DMA により GPU バッファへ転送され、デュアルバッファ間で計算と重ね合わせて実行されます。 - **Roadmap（ロードマップ）**：完成済みフェーズ—基盤、SLEP ストリーミング、最適化、NVMe direct。今後の作業には speculative decoding の仕上げと公開 C API の追加が含まれます。 NTransformer は、大規模モデルをコストの高いサーバーインフラなしでコンシューマ GPU 上にローカル実行できるようにすることで、推論コストを低減し、オンプレミス AI サービスのレイテンシを削減し、研究・産業界全体での採用拡大を促進します。

2026/02/22 4:40

**「Rustにおけるパース・非検証設計と型駆動開発」**

## 日本語訳: **要約** この記事は、Rust の型システムを利用して、プリミティブ値を *newtype* でラップすることでコンパイル時にドメイン不変条件をエンコードできることを示しています。生成関数を失敗可能（例：`NonZeroF32::new` が `Option<NonZeroF32>` を返す）にすることで、値がゼロでないことを保証します。その後、関数は生のプリミティブではなくこれら newtype を受け取るようになり、検証を関数内部から呼び出し前へ移動させ、冗長なランタイムチェックを排除します。同様のパターンが `NonEmptyVec<T>` にも適用されます。これはベクタが空でないことを保証し、`first()` のような安全メソッドを追加のガードなしに提供します。著者は、これを `Option` や `Result` を返す通常の失敗可能関数と対比し、より強力な型保証が API 契約をどれだけ簡素化するかを強調しています。実際の例として、Rust 自体の `String` は検証済み `Vec<u8>` の newtype であり、Serde は JSON をデシリアライズしてコンパイル時にスキーマ制約を課す具体的な構造体へ変換できます。また、記事は「ショットガン解析」や Curry–Howard 対応といった関数型プログラミングの概念も参照し、タイプによる早期かつ包括的な検証の動機付けを行っています。実務上のアドバイスとして、より意味のある型（例：単なるブールフラグではなく `LightBulbState` のような列挙体）が正確性を向上させる場合はプリミティブを避けるべきです。newtyping はコードを冗長にすることがありますが、一般的にはより明確で安全な API を提供し、ランタイムエラーを減らします。主な制限点は、Rust が現在 newtype 用のエルゴノミック委譲（delegation）をサポートしていないことであり、将来の RFC やライブラリがこの障壁を低くする可能性があります。この要約はキーポイントリストからすべての主要点を捉えつつ、メッセージを明確に保ち、余計な推論を排除しています。

**Claude コードの使い方：計画と実行の分離**