近年ゲリラ豪雨など水害による被害が発生しています。このような都市部での水害をシミュレーションすることは都市設計の観点から有益な取り組みの1つになります。 そこで、都市水害シミュレーションをOpenFOAMというCFDフレームワークを用いて実行することを目的にその手順についてまとめていきたいと思います。 ※CFD（Computational Fluid Dynamics、流体解析）フレームワーク OpenFOAMは都市水害で多く利用されるVOF法を実装しているOSSであり、メッシュ生成などCFDに必要となる機能を網羅しているため採用しています。 本記事ではOpenFOAMの環境構築について

はじめに GitHub Copilotは導入しやすい開発者向けAIの1つですよね。Copilot CLIは便利で普段の開発でも頻繁に利用するものになっていますが、このAIの力をワークフローに組み込めるとしたら素晴らしいことです。そこで業務で使い道のあるドキュメンテーションの観点においてCopilot SDKを利用して自動ドキュメント生成ツールを作ってみました。コードで制御させることはスキルなどでMust, Shouldを書くよりも強力であり、さらにCopilotの活用の余地が広がると感じます。 https://github.com/github/copilot-sdk この記事では、

はじめに ども！龍ちゃんです。皆さん、Spec駆動開発やってますか？ AIが出てきて、開発スピードが爆上がりしたり、開発を丸投げできたり、いろんなことができるようになりましたよね。そんなAI駆動開発の文脈でよく語られるのが Spec駆動開発（SDD） です。 SDDツールも色々出てきてます。Kiro、Spec Kit、AI-DLC…。でも、新しいツールを導入するには学習コストがかかりますよね。プログラミング言語と同じで、「じゃあそのツールを勉強しなきゃ」となる。 「Claude Code契約したし、まずは小さく始めたい」 実は、Claude Codeの標準機能 /plan を使えば、Spec駆動開発の基本はできます。計画を立ててから実装する、という流れは標準でサポートされています。 ただ、使っていくうちに「もうちょっとこうしたい」が出てくるんですよね。今回は、標準の /plan を拡張したカスタムコマンド /feature-plan を紹介します。 関連記事 記事 内容 静的情報で実行速度を改善 ドメイン知識の管理方法 AIフレンドリーなドキュメント管理 READMEインデックス戦略 CLAUDE.md vs .claude/rules/ 設定ファイルの使い分け /research コマンドで調査品質を安定化 調査結果の資産化 この記事 カスタムコマンドで計画フェーズを標準化 標準Plan Modeの進化 2026年1月頃、標準の /plan モードに 待望の機能 が追加されました。 plansDirectory で保存先を変更できるようになったんです。 // .claude/settings.json { "plansDirectory": "./docs/plans" } 今まではホームディレクトリ配下（ ~/.claude/plans/ ）に保存されていたのが、任意の場所に保存できるようになりました。これで計画書をGit管理できます。 計画書が資産として保存できるようになった。 これは大きな進化です。 標準Plan Modeの限界：ドメイン知識の不足 ただ、保存できるようになっただけでは足りないんですよね。 良い計画を作るには、 リポジトリのドメイン知識 が必要です。まっさらなリポジトリならいいんですけど、機能追加の時って： プロジェクトの基盤情報 既に何が実装されているか どのディレクトリに何があるか プロジェクト固有の設計方針 これらを理解した上で方向性を決める必要があります。 標準の /plan を打つときって、プロンプトしか入力できないですよね。プロジェクトが大きくなると、毎回ドメイン知識を説明するのは面倒です。 カスタムコマンドなら、打った段階でリポジトリのドメイン知識を自動で読み込ませることができます。 /feature-plan で標準を補完する 僕が作った /feature-plan コマンドは、標準Plan Modeの足りない部分を補完します。 📎 原文は Gist で公開しています。以下では要点を抜粋して説明します。 出力の補完：plan.md + action-plan.md 標準のPlan Modeだと、特別な指示がなければ plan.md しか作りません。これだけだと 手戻りが発生する なと感じていました。 そこで、2つのファイルを作らせることにしました： ファイル 役割 用途 plan.md 何を作るか（Why / What） 人間が確認・承認 action-plan.md どう作るか（How） 人間が確認 + AIが進捗管理 plan.md には設計判断を書きます： ## 代替案の検討 | アプローチ | メリット | デメリット | 採用 | |------------|----------|------------|------| | 案A | シンプル | 拡張性が低い | × | | 案B | 拡張しやすい | 複雑 | ○ | ## リスクと対策 | リスク | 影響度 | 対策 | |--------|--------|------| | 既存機能への影響 | 中 | 回帰テストを追加 | action-plan.md には実装ステップと対象ファイルを書きます： ### ステップ 1: CLIエントリーポイントの作成 - **対象ファイル**: `src/cli.py`（新規） - **完了基準**: `uv run cli --help` でヘルプが表示される ### ステップ 2: コア機能の実装 - **対象ファイル**: `src/core.py`（新規） - **完了基準**: ユニットテストが通る なぜ2つに分けるのか？ レビュー時に両方見ると、 意図と違う実装を事前に検知できる んです。 action-plan.md に意図していないファイルが書いてあったら、「いや、そうじゃなくて…」と指示を修正できます。自分のプロンプトが悪かったのか、Claudeの解釈が違ったのか、この段階で発見できるのが大きいです。 あと、rate limitでセッションが中断したり、セッションが切れたりしても、 ファイルに進捗が残っている ので戻ってこれます。どこまでやったか把握しやすいんですよね。 入力の補完：ドメイン知識の注入 カスタムコマンドのもう一つの利点は、 計画フェーズ特有の指示を埋め込める ことです。 ## CRITICAL CONSTRAINTS 1. **Read-only analysis first**: 既存コードを先に分析する 2. **Output directory**: 出力は `docs/features/$ARGUMENTS/` に保存 3. **Language**: ドキュメントは日本語で出力 僕は他にも /research コマンドで調査結果を docs/research/ に保存しています。これらの資産と統合しやすいのもカスタムコマンドの良いところです。 /feature-plan の実装例 実際のコマンドファイルはこんな構造です： 配置場所 : .claude/commands/feature-plan.md frontmatter --- description: 実装計画とアクションプランを作成し、docs/features/ に保存。機能開発の計画フェーズをサポートします。 argument-hint: [feature-name] allowed-tools: Read, Glob, Grep, Task, Write, Bash, WebSearch, WebFetch, TodoWrite, AskUserQuestion --- description : コマンドの説明（ /help で表示される） argument-hint : 引数のヒント（ $ARGUMENTS で受け取る） allowed-tools : 使用可能なツールを制限 CRITICAL CONSTRAINTS（重要な制約） コマンド本文の冒頭で、守るべきルールを明示しています： ## CRITICAL CONSTRAINTS You MUST follow these rules strictly: 1. **Read-only analysis first**: Do NOT modify any existing code until the plan is approved 2. **Output directory**: All documents MUST be saved to `docs/features/$ARGUMENTS/` 3. **Create subdirectory**: First create the directory before saving files 4. **Language**: Write all documents in Japanese これにより「計画が承認されるまでコードを変更しない」という原則を徹底できます。 Workflow Phases（5フェーズ） Phase 1: Initial Understanding - 要件の明確化、コードベース分析 Phase 2: Design - 実装アプローチ、リスク評価 Phase 3: Review - ユーザー要求との整合性確認 Phase 4: Create Documents - plan.md、action-plan.md 作成 Phase 5: Summary - ユーザーへのサマリー提示 各フェーズで何をすべきかを明記することで、Claudeの動作が安定します。 使い方 /feature-plan thumbnail-generator これで docs/features/thumbnail-generator/ に plan.md と action-plan.md が作成されます。 📎 /feature-plan の全文は Gist で公開しています。 テンプレートの詳細やTodoWrite連携など、試したい方はそちらを参照してください。 Tips：英語記述で思考精度を向上させる これ、めちゃくちゃ余談なんですけど。 /feature-plan コマンドは 英語で記述 しています。Claudeは英語の方が思考能力が高いと言われているので、CLAUDE.md で「思考は英語、出力は日本語」と指示しています。 あと、ドメイン知識の注入も、読み出すファイルやディレクトリを固定化しておけば、 /feature-plan は使い回しできます。静的情報として管理しておくのがおすすめです。 まとめ 観点 標準 Plan Mode /feature-plan 用途 アドホックな調査 正式な機能追加 出力形式 Claudeに委ねる テンプレートで標準化 ドメイン知識 プロンプトで毎回説明 コマンドに埋め込み 進捗管理 なし action-plan.md で管理 Spec駆動開発を始めるのに、新しいツールを導入する必要はありません。 カスタムコマンド1つで小さく始められます。 plan.md で意思決定を記録 action-plan.md で変更先を確定し、進捗を管理 カスタムコマンドでドメイン知識を自動注入 必要に応じてテンプレートを調整し、チームの運用に合わせて進化させていけばOKです。 ここまで読んでいただき、ありがとうございました！ 参考リンク 公式ドキュメント Claude Code – Slash commands Claude Code – Common workflows Claude Code – Settings Gist /feature-plan 原文 ご覧いただきありがとうございます！ この投稿はお役に立ちましたか？ 役に立った 役に立たなかった 0人がこの投稿は役に立ったと言っています。 The post Claude CodeでSpec駆動開発 – AI駆動時代の計画術 first appeared on SIOS Tech Lab .