仕様書の読み方
houki-hub family の MCP サーバー・ライブラリ・Skill が「何をするか」を、ツール（関数）ごとに 1 ページで説明しています。ツールを何のために使い、呼び出してから応答を返すまでにどう処理するかを知りたいときに読むページです。
どのページを読むか
この節は、知りたいことに合わせて、仕様書・リファレンス・解説のどれを読めばよいかを示します。
| 知りたいこと | 読むページ |
|---|---|
| ツールが何のためのものか、どの順に処理するか、どんなときに何を返すか | 仕様書（このページから辿るページ） |
| 引数の型・既定値の一覧と、実測の呼び出し例 | リファレンス（houki-egov-mcp・houki-nta-mcp・houki-abbreviations） |
| 導入の手順と、部品ごとの全体の使い方 | ガイド と、MCP サーバー・ライブラリ・Skill の解説 |
| 自分の立場で何に使えて何に使えないか | 利用者ごとにできることとできないこと |
仕様書の一覧
この節は、部品ごとの仕様書の入口を示します。
- houki-egov-mcp の仕様 — e-Gov 法令 API とローカル DB から、法律・政令・省令を引くツール
- houki-nta-mcp の仕様 — 国税庁の通達・質疑応答事例・タックスアンサーなどを引くツール
- houki-abbreviations の仕様 — 略称の解決と表記の揃え方を MCP サーバーに提供する関数
- houki-research Skill の仕様 — 問いの形ごとに、どのツールをどの順に呼ぶかの手順（workflow）
ページの組み立て
この節は、仕様書ページのどこまでが元の仕様書の写しで、どこが足した部分かを示します。
各ページは、それぞれのリポジトリの仕様書（specs/current/<機能>/spec.md）から自動で作っています。本文は言い換えずに写しているので、エラーの code やフィールド名がそのまま出てきます。仕様書は実装する人に向けても書いているためです。
ページの上から順に、次の節が並びます。
| 節 | 内容 |
|---|---|
| 利用者と得られる結果 | 誰が使い、何を渡して何を得るか |
| 入力・戻り値 | 渡す値と返る値 |
| 値 | 公開している値と、その中身（ライブラリの値のページだけ） |
| 対象 | 共通の規則が当てはまる範囲（共通の規則のページだけ） |
| 扱わないこと | その機能が意図して扱わないこと |
| 処理の流れ | 呼び出しを受けてから応答を返すまでの順序の図 |
| 仕様項目 | 機能の仕様項目の一覧。条件と例は折りたたんであります |
| 実装する人に向けた情報 | ここから下は実装する人と、仕様の変更を追う人に向けた節です。使い方を知りたいだけなら読まなくて構いません。次の 2 つを含みます |
| ↳ 検討中のこと | 扱いを Issue で検討している項目。今後の版で変わることがあります。元の仕様書の記述を折りたたんであります |
| ↳ 承認の履歴 | 仕様がいつ、どの変更で決まったか |
本文は言い換えずに写していますが、節の見出しは利用者が読みやすいように、このサイト用の名前に置き換えています。元の仕様書の見出しとの対応は次のとおりです。
| 元の仕様書の見出し | このサイトの見出し |
|---|---|
| アクター | 利用者と得られる結果 |
| できないこと | 扱わないこと |
| できること | 仕様項目 |
| 未決 | 検討中のこと |
本文の中で「「できること」の仕様 ID」「未決 1」のように元の見出しで書かれているときは、このページの対応する節を指します。
自動生成の側で足しているのは、節の目的の一文、承認の履歴の表、関連ページの一覧だけです。人が書いて補う「使いどころ」の節は、仕様書ページではなく、リファレンスのツールのページに載せています。
Skill には実行するコードが無く、SKILL.md の文章そのものが仕様です。そのため Skill のページには仕様 ID と承認の履歴が無く、問いの形（workflow）ごとに、SKILL.md と workflow の本文を写しています。
仕様 ID
この節は、ページの中の SPEC-… という番号の意味を説明します。
仕様 ID は SPEC-<部品>-<機能>-<3 桁の番号> の形です（例: SPEC-NTA-GET-TSUTATSU-007）。1 つの仕様 ID が 1 つの仕様項目を表し、各リポジトリの受入テストの名前に同じ ID が入っています。仕様書にあってテストに無い ID や、テストにあって仕様書に無い ID があると、各リポジトリの CI が止まります。そのため、ページに書かれた仕様項目は、その版のテストで確かめられています。
処理の流れの図の中にある 3 桁の番号は、仕様 ID の末尾の番号です。
承認の履歴
この節は、各ページの末尾にある表の読み方を説明します。
仕様を変えるときは、何をなぜ変えるかを書いた文書を作り、仕様の PR で承認を受けてから実装します。表の 1 行が承認された 1 つの変更で、承認日・その変更が入った版・変更の文書・仕様の PR を示します。「次の版（未公開）」の行は、承認済みでまだ公開していない変更で、ページの本文にはまだ入っていません。