Upgrade to Pro — share decks privately, control downloads, hide ads and more …

月間100万人のサービス刷新で、 技術選定をHonoに振り切った話

Avatar for bara bara
October 11, 2026

月間100万人のサービス刷新で、 技術選定をHonoに振り切った話

Hono Conference 2026 の登壇資料です。月間100万人のサービスを6人とAIで作り直しました。AIを迷わせない開発の土台作りと、Honoが効いた理由について、紹介しています。

Avatar for bara

bara

October 11, 2026

Other Decks in Programming

Transcript

  1. 01 事業背景 自己紹介 今日はIRBANKの話 いま これまで IRBANK Sansan(Bill One) ソフトウェアエンジニア

    / アーキテクト エンジニアリングマネージャー / 部長 タイミー デジタルプラットフォーマー エンジニアリングマネージャー / アーキテクト VPoE / アーキテクト ディーカレットDCP ソフトウェアエンジニア / マネージャー 趣味:どデカいシステム、ジャズギター、料理、酒 X: @EthicalTx GitHub: yutonano Hono Conference 2026 2
  2. 今日の流れ 事業背景 01 IRBANK、なぜ今作り直すのか、何が難しいか、4月から今日まで に起きたこと 03 開発前に揃えるもの 05 やめたこと 07

    再現キット 言語、Hono、ファイルの置き場所、Lint アンチパターン5つと、Honoでぶつかったこと5つ 始める順番と、そのまま写せる雛形 Hono Conference 2026 02 ハーネスとは 04 フェーズ別の手順 AIの外側に置く4種類の仕組みの定義 設計から学習までの6フェーズ ハーネスとは何だったのか 06 08 重心の変化、人は中身を分かっているのか、得られた速さ、一言 での総括 まとめ 持ち帰ってほしい3つ 3
  3. 01 事業背景 IRBANK 上場企業の決算・開示・市場データを一か所に集め、個人投資家が 読める形で届けるサービス 月間の利用者 約100万人 企業ページ 決算 適時開示

    有価証券報告書 業績、財務、CF、配当、セグメ ントの推移や、株価、PER / PBR / ROEなど 決算速報、発表スケジュール、 予想と修正、決算説明 決算、配当、優待、M&A、月 次、株式関連などを分類して 検索 臨時報告書、役員や会計士の異 動、株主総会 大量保有 信用・空売り ランキング その他 投資家ごとの投資先一覧など 信用残、貸借と逆日歩、空売り 残高 企業、監査法人、値上がり率、 逆日歩などのランキング IPO、法人番号の変更、官公庁 の届出・調達、CSV / JSON Hono Conference 2026 4
  4. 01 事業背景 今やっていること:IRBANKの全面刷新 何を 誰が いつから サービス 全面刷新 6人 +

    AI 2026.03 社員2人と副業4人。そしてAI 本格的に開始 IRBANKを新しい基盤で作り直すして いる。 Hono Conference 2026 6
  5. 01 事業背景 難しさ1:データの取り込みが多い 取り込み元 内容 官公庁の開示 有価証券報告書、財務データ 適時開示 決算短信、開示資料 取引所・証券金融会社など

    株価、信用取引、貸借、空売り 外部のデータ提供サービス 米国株価、経済指標 13 データのパイプラインを担う専 用アプリの数 形式も更新時刻も違うデータを、毎 日決まった時刻に決まった順番で取り 込む。 Hono Conference 2026 9
  6. 01 事業背景 難しさ2:数字を間違えられない 株式分割 予想と実績 過去の訂正 分割前の配当と分割後の株価を混ぜる どの決算期の予想を使うか、予想を止 あとから訂正された開示を、過去のどの と、利回りが何倍にも跳ね上がる。

    めた会社をどう扱うかで、利回りが変 日まで遡って反映するか わる。 1つの数字の裏に、株式分割、決算期、予想と実績、訂正などが絡む 利用者はこの数字を見て投資の判断をする Hono Conference 2026 10
  7. 01 事業背景 難しさ3:性質の異なるデータが同居している 作り直せる 失ったら戻せない 加工後データ 市場データ ユーザーと課金 市場データを加工したデー タ。スクリーニング機能で使

    用している。元のデータから 何度でも作り直せる。 外部の一次情報から取得して いる。 失うと利用者に直接響く。 ポイントの台帳と操作 の履歴 ユーザーの操作履歴やポイン ト台帳。失ったら戻せない。 性質ごとにデータベースを分け、扱い方も変えている Hono Conference 2026 11
  8. 01 事業背景 難しさ4:時間がない 2026.3 2026.4下旬 2026.5 2026.6下旬 本格的に開発を開始 β環境とデプロイの経路 を用意

    スクリーニングを3日で 組み上げる。 βを本番に公開 4か月 Hono Conference 2026 本格開始から公開まで、4か月足らず 完成を待ってから出す余裕はなかった。βを爆速で出して、出しながらフィードバックを取り入れた。 12
  9. 01 事業背景 これを6人でやっている 2+4 2026.3 100万人 社員2人+副業4人 開発開始 既存ユーザーへの影響を考慮しながらの 移行

    人の手だけでは間に合わない。それは最初から分かっていた。 Hono Conference 2026 13
  10. 01 事業背景 2026年4月から今日まで 4/1 5/1 6/1 7/1 10/6 TypeScriptの行数 2万

    9万 76万 122万 237万 うちテストコード 0.8万 3.6万 24万 43万 103万 Webサービスとバッチの数 6 9 20 27 34 Honoで書いたHTTPサーバー 3 6 13 16 21 createRouteの数 2 15 177 257 407 自作Lintルール 0 0 17 21 34 コミット数(累計) 763 2,386 3,952 5,733 8,297 5月の1か月だけで、9万行から76万行に増えた 6/1と7/1の間、6月24日にβを本番に公開 createRouteと自作Lintルールは、03章で説明する。 Hono Conference 2026 14
  11. 01 事業背景 マージされたPRの9割以上に、AIが関わっている 95% 97% 95% 96% 92% 92% 4月

    5月 6月 7月 8月 9月 719本 1,413本 1,688本 775本 668本 629本 Hono Conference 2026 16
  12. 今日の流れ(再掲) 事業背景 01 IRBANK、なぜ今作り直すのか、何が難しいか、4月から今日まで に起きたこと 03 開発前に揃えるもの 05 やめたこと 07

    再現キット 言語、Hono、ファイルの置き場所、Lint アンチパターン5つと、Honoでぶつかったこと5つ 始める順番と、そのまま写せる雛形 Hono Conference 2026 02 ハーネスとは 04 フェーズ別の手順 AIの外側に置く4種類の仕組みの定義 設計から学習までの6フェーズ ハーネスとは何だったのか 06 08 重心の変化、人は中身を分かっているのか、得られた速さ、一言 での総括 まとめ 持ち帰ってほしい3つ 18
  13. 02 ハーネスとは ハーネスの前提 ハーネスは、AIの外側に置く仕組み全体のこと コンテキスト 機械的チェック 検証 再発防止 AIが読む文書。意思決定の結 果だけを渡し、量は絞る。

    型チェック、Lint、フック が、書いた時点で機械的に止 める。 AIと協業し、実データ、CI で、できたものを確かめる。 見落としをLintやskillにし て、2回目は機械で止める。 Hono Conference 2026 19
  14. 今日の流れ(再掲) 事業背景 01 IRBANK、なぜ今作り直すのか、何が難しいか、4月から今日まで に起きたこと 03 開発前に揃えるもの 05 やめたこと 07

    再現キット 言語、Hono、ファイルの置き場所、Lint アンチパターン5つと、Honoでぶつかったこと5つ 始める順番と、そのまま写せる雛形 Hono Conference 2026 02 ハーネスとは 04 フェーズ別の手順 AIの外側に置く4種類の仕組みの定義 設計から学習までの6フェーズ ハーネスとは何だったのか 06 08 重心の変化、人は中身を分かっているのか、得られた速さ、一言 での総括 まとめ 持ち帰ってほしい3つ 20
  15. 03 開発前に揃えるもの AIが迷う選択肢を減らす4つの決めごと 言語を1つに フロントからバッチ、Lint のルールまでTypeScript AIの間違いを、型検査が一 番早く止める。 フレームワークを1 つに

    ディレクトリの責務 を明確化する HTTPを使用するアプリは 全部Hono ディレクトリの層と importの向きを決める。 1つ読めば、残りのアプリも 読める。 AIがファイルの置き場所で 迷わない。 規約はLintに書く 守ってほしいことはプロン プトではなくLintへ AIが忘れても、Lintで止 まる。 AIに仕事を渡す前に、この4つを先に揃える Hono Conference 2026 21
  16. 03 開発前に揃えるもの 揃えるよう意思決定したもの 役割 揃えたもの 数 言語 TypeScript ファイル14,000超 HTTPを受けるサーバー

    Hono 4.13(全アプリ同じ版)+ @hono/zod-openapi + Zod 4 21アプリ HTTPを受けないバッチ フレームワークなし 12アプリ(共有パッケージは17 アプリが利用) 実行環境 Bunでビルド、Node 24で実行。 34アプリ その他開発ツール tsc、oxlint(自作ルール34本込み)、Biome、Nx、bun test、lefthook 全アプリ共通 HTTPを受けるサーバーは全てHono。 Hono Conference 2026 22
  17. 03 開発前に揃えるもの / 言語を1つに なぜTypeScriptにしたのか 正確に書ける 爆速に書ける 実行する前に型検査で止められる。 公開されているコードが多く、AIが最も安定して書ける言 Zodのスキーマ1つから、型推論、バリデーション、

    語の1つ OpenAPI Documentを生成できる。 AIがその場でTypeScriptのLintルールを書いて足せる。 画面(Next.js)と同じ言語なので、型が画面からバッチまで1 Bun、oxlint、Biomeのような速いツールが揃い、書く、試 本でつながる。 す、直すの待ち時間が短い。 TypeScriptを選んだのは、この両方を満たせるから。Honoはこの言語の上に乗る。 Hono Conference 2026 23
  18. 03 開発前に揃えるもの / フレームワークを1つに なぜHonoにしたのか 作るのが速い 動くのが速い 軽くて、起動もテストも一瞬 100万人が使う画面の裏側で動く。 サーバーを立てずに試せる。

    APIでもゲートウェイでも、フレームワーク自体の処理が 書き方が1つに決まる。 軽い。 簡単に作り直せる。 フレームワーク選定も、AIが正確かつ爆速に書けるか Hono Conference 2026 24
  19. 03 開発前に揃えるもの / フレームワークを1つに HTTPを受ける21個のアプリが、全部Hono 6 1 8 4 2

    API ゲートウェイ データの取り込み 社内ツール ドキュメント アプリ本体 APIゲートウェイ 国内の開示 ×2 管理画面 外部公開APIの文書 市場データ 米国の開示 監査ログの閲覧 仕様サイト AIアシスタント 米国株価 インフラ操作 検索 指標の集計 バグ報告のbot 認可 スクリーニングの投影 テナント管理 検索の索引 イベントの書き込み 用途ごとに最適なものを選ぶより、ナレッジを横展開出来る事を優先した Hono Conference 2026 25
  20. 03 開発前に揃えるもの / フレームワークを1つに ルート定義が型推論・バリデーション・OpenAPIを担う // 市場データ API: 指数の日次価格 const

    getIndexPricesRoute = createRoute({ method: "get", path: "/{code}/prices", 407 現在のcreateRouteの数 tags: ["indices"], operationId: "getIndexDailyPrices", summary: "指数日次価格", request: { params: indexCodeParamSchema, query: indexPricesQuerySchema, }, responses: { 200: { content: json(indexPricesResponseSchema), description: "OK" }, 400: { content: json(httpErrorBodySchema), description: "不正" }, }, }) operationIdが、そのまま自動生成される フロントのhookの名前になる。 Hono Conference 2026 26
  21. 03 開発前に揃えるもの / フレームワークを1つに ルートを1つ足すと、OpenAPI、フロントの型、ドキュメ ントを自動で更新する createRoute OpenAPIのJSONを 生成 Orvalでフロントの

    コードを生成 ルート定義(Zodスキーマ) 画面用 / 公開API用 / 外部 TanStack Queryのhook 連携用 と型 APIドキュメント 仕様サイトと外部向けの文 書に反映 ルートを変えたのにJSONを再生成していないPRは、CIが落とす 我々がHono ClinetでAppTypeを直接importを使わない理由 公開APIと外部連携にはOpenAPIが要る。画面だけRPCにすると正本が2つになる。407ルート分の型推論でビルドも重くなる。 小さく始めるなら:createRouteで書き、OpenAPIの再生成漏れをCIで落とす。 Hono Conference 2026 27
  22. 03 開発前に揃えるもの / フレームワークを1つに Orvalの設定で決めていること APIのURLはSchemaから取る // Orvalの設定(抜粋) marketDataApiHooks: {

    input: { target: "../market-data-api/openapi/client.openapi.json", }, output: { mode: "tags-split", client: "react-query", フロントの環境変数にURLを持たない。環境ごとの違いは Schema側にだけある。 通信は1つの関数にまとめる 生成されたhookは全部この関数を通る。Cookieの付与、 レスポンスの取り出し、エラーの型変換などを共通化で きる。 baseUrl: { getBaseUrlFromSpecification: true }, override: { mutator: { path: "src/lib/orval-mutator.ts", name: "customFetch" }, }, clean: true, }, }, 小さく始めるなら:OpenAPIのJSONからhookを生成し、画面側でfetchを手書きしない。 Hono Conference 2026 28
  23. 03 開発前に揃えるもの / フレームワークを1つに エラーハンドリングの定義を統一する 例外 status error code ValidationError

    / ZodError 400 VALIDATION_FAILED UnauthorizedError 401 UNAUTHORIZED ForbiddenError 403 FORBIDDEN NotFoundError 404 NOT_FOUND ConflictError 409 CONFLICT TooManyRequestsError 429 RATE_LIMITED それ以外 500 INTERNAL_ERROR // 各アプリ app.onError(errorHandler) // 共有パッケージ export const errorHandler = createErrorHandler({ logger, ... }) 4xxは警告ログだけ。5xxはエラー監視に送り、メッセー ジを伏せる。 小さく始めるなら:例外のクラスと、返すJSONの書式の対応表を1か所に置く。 Hono Conference 2026 29
  24. 03 開発前に揃えるもの / フレームワークを1つに サーバーを立てずにテストできる // 結合テスト(簡略) test("存在しない指数コードは 404", async

    () => { const app = createApp({ deps: fakeDeps }) const res = await app.request( "/indices/UNKNOWN/prices?from=2026-01-01", ) expect(res.status).toBe(404) }) app.request() ポートの競合を気にせず、書 く、試す、直すを何度でも繰り 返せる。 RequestとResponseはWeb標準 なので、AIが持っている一般的な 知識をそのまま使える。 小さく始めるなら:新しいルートにはapp.request()のテストを必ず1本付ける。 Hono Conference 2026 30
  25. 03 開発前に揃えるもの / フレームワークを1つに フレームワークのまとめ:Honoの何が、ハーネスのどこ に効いたか Honoの機能 IRBANKでの使い方 ハーネスでの役割 createRoute

    ルート定義が型推論、バリデーション、OpenAPIを兼 ねる。OpenAPIからフロントのhookを生成 機械的チェック:推論された型とリクエス トのバリデーション コンテキスト:生成されたコードがAIの手 本になる。 app.request() サーバーを立てずにテスト。約420ファイル 機械的チェック:素早くテストできる。 app.onError() 共有のエラーハンドラで、返す書式を1つに 機械的チェック:エラーの書式がばらつか ない。 app.route() サブアプリ 認証、権限、ログのような共通処理は、専用の関数で 作ったアプリにまとめる。 機械的チェック:共通処理の付け忘れと順 序の崩れが起きない。 Hono Conference 2026 31
  26. 03 開発前に揃えるもの / ディレクトリの責務を明確化 AIが正確かつ爆速に書くため、モノレポ構成にした 1 AIは近くのコードを真似する どのアプリを読んでも正しい手本になる。書 き方が2つあると、どちらに合わせるか毎回 迷う。

    4 型が画面からバッチまでつな がる Zod → OpenAPI → 画面の型。利回りなどの 計算もバッチとAPIで1か所に置ける。 2 規約を1回書けば全体に適用さ れる 自作Lint 1本が全てのアプリに適用される。 Honoの書き方のskillも1本で済む。 5 CIとDockerfileが1種類で済む Dockerfile 34本が同じ構成。 3 共有パッケージを作れる エラーレスポンスの書式、サービス間の認 証、データ型、ログ出力 6 誰でも貢献できる 6人のうち4人は副業。どのアプリでも、す ぐ読んでレビューできる。 捨てたもの:Pythonの定番ライブラリ(データ処理など)など、用途ごとに最適な言語やフレームワークを選ぶ自由を捨てた。困 難な意思決定だった。 Hono Conference 2026 32
  27. 03 開発前に揃えるもの / ディレクトリの責務を明確化 モノレポの中身 場所 数 中身 apps/ 34

    Hono 21、HTTPを受けないバッチ、Web packages/ 17 共有パッケージ。証券コード、評価指標の計算、 エラーの型、認可、ログ、UI部品 など eslint-rules/ 34 自作Lint。実装、テスト、説明文書の3点セット ルートからフロントの型まで1つのPRで AIが最初に読む入口の文書 Honoのルート、OpenAPIのJSON、Orvalが生成するフ ロントの型を同じPRで更新する。生成物が古いままの PRはCIが落とす。 AGENTS.md .claude/ 8 ルール文書と、skill infra/ Terraform。環境、モジュール、runbook docs/, spec/ 設計書とADR、仕様 .github/workflows/ 52 CIとCD。PRごとの検査と、アプリごとのデプロイ apps/*/Dockerfile 16 Dockerfile。Bunでビルドし、Node 24で動かす。 ルートの設定 Hono Conference 2026 bun、Nx、Biome、oxlint、lefthook。全アプリ で同じ設定 計算は共有パッケージに1つだけ置く 利回りや証券コードの計算は packages/ に1つ置き、画 面もバッチもそれをimportする。 Lint、CI、Dockerfileの構成が全アプリで 共通 Lint、フォーマット、テストの設定はルートに1つ。CI とDockerfileはアプリごとにあるが、構成は全部同じ。 新しいアプリは隣のアプリをコピーして作る。 33
  28. 03 開発前に揃えるもの / ディレクトリの責務を明確化 ディレクトリ構成を規定し、依存関係をLintで強制する どのアプリも、機能ごとに同じ4層に分ける // Lint の設定(抜粋) "boundaries/elements":

    [ { "type": "domain", "pattern": "src/modules/*/domain/**" }, { "type": "application", "pattern": "src/modules/*/application/**" }, { "type": "infrastructure", "pattern": "src/modules/*/infrastructure/**" }, { "type": "interface-mcp", "pattern": "src/modules/*/interface/mcp/**" }, { "type": "interface-external", "pattern": "src/modules/*/interface/external/**" }, { "type": "interface-http", "pattern": "src/modules/*/interface/http/**" }, ] Hono Conference 2026 interface 入口。画面向けAPI、外部公開API、MCP の3種類 application 手順。入口から受けた要求を組み立てて 実行する。 domain 業務のルールと計算。ほかの層に依存し ない。 infrastructur DBや外部サービスとのやり取り e 層をまたぐimportの向きをLintで決める 既定は全部禁止。入口から業務ルールへ向かう向きだけ許 し、逆向きは止める。domainは何もimportしない。入口 の3種類は互いをimportできない。 AIは「このコードをどこに置くか」で迷わない。置き場所 を間違えればLintで止まる。 34
  29. 03 開発前に揃えるもの / 規約はLintに書く 守ってほしいことはLintに書く プロンプトの指示は抜け落ちる Lintが厳しいほどAIは爆速で直せる 作業が長引くと、指示は抜け落ちる。Lintに書いておけ 指摘が具体的なほど、AIは迷わず直せる。説明文書に書い ば、忘れても必ず止まる。

    た違反例と直し方が、そのままAIの手がかりになる。 入口の文書となるAGENTS.md はなるべく短く。細かい規 Lintは速い。型情報を使うルールもcommit前に数秒で回 約はLintと、必要なときだけ読まれるルール文書へ るので、AIは書いて、指摘されて、直すを何度でも繰り返 せる。 小さく始めるなら:Lintの無効化コメントを禁止し、AIが2回同じ間違いをしたらLintルールにする。 Hono Conference 2026 35
  30. 03 開発前に揃えるもの / 規約はLintに書く 自作のLintルールは34本(現在) 分類 本数 守らせること Hono /

    API 3 ルート定義の書き方 セキュリティ 4 認証、権限、ユーザー間のデータ 境界 どのルールも3点をセットで置く 実装 テスト 文書 無効化コメントは禁止。AIは行き詰まると無効化しようとす るので、その手段をなくしておく。 ドメイン 3 証券コードや決済情報を生のまま 扱わせない。 TypeScript / React 10 読みにくい書き方を禁止 デザインシステム 12 色や文字サイズの直書きの禁止 テスト 2 モジュール丸ごとの差し替えの禁 止 Hono Conference 2026 36
  31. 03 開発前に揃えるもの / 規約はLintに書く 例1:リクエストボディには「required: true」を必ず付 ける NG: 付け忘れると、Content-Typeが無いリクエストはバリデーショ ンされない

    OK: 必須項目が無ければ400を返す request: { request: { body: { body: { required: true, content: json(bodySchema), content: json(bodySchema), }, } }, } required: trueが無いと、@hono/zod-openapiはContent-Typeが合わないリクエストでZodのバリデーションを行わず、空のオブジェクトをハ ンドラに渡す。 Hono Conference 2026 37
  32. 03 開発前に揃えるもの / 規約はLintに書く 例2:サブアプリは、必ず専用の関数で作る NG: new Hono()で組み立てる OK: 専用の関数で作る

    const protectedApp = new Hono<AppEnv>() const protectedApp = createUserAuthSubApp({ protectedApp.use("*", createSessionAuth({ ... })) acceptedScopes: ["web"], // acceptedScopes を忘れても authMiddleware: createSessionAuth({ ... }), // 型では気づけない }) // 認証 → 権限 → 主体の付与の順が固定 以前、認証を通らずにバックエンドへ届く経路を作ってしまったことがあり、このルールを足した。Web向け、MCP向け、外部API向けの3つの サブアプリは、すべてこの関数で作っている。 Hono Conference 2026 38
  33. 今日の流れ(再掲) 事業背景 01 IRBANK、なぜ今作り直すのか、何が難しいか、4月から今日まで に起きたこと 03 開発前に揃えるもの 05 やめたこと 07

    再現キット 言語、Hono、ファイルの置き場所、Lint アンチパターン5つと、Honoでぶつかったこと5つ 始める順番と、そのまま写せる雛形 Hono Conference 2026 02 ハーネスとは 04 フェーズ別の手順 AIの外側に置く4種類の仕組みの定義 設計から学習までの6フェーズ ハーネスとは何だったのか 06 08 重心の変化、人は中身を分かっているのか、得られた速さ、一言 での総括 まとめ 持ち帰ってほしい3つ 39
  34. 04 フェーズ別の手順 IRBANKのAI-DLC:6つのフェーズ 1 2 3 4 5 6 設計

    実装 検証 リリース 運用 学習ループ 担当: 人 + AI 担当: AI 担当: AI + 人 担当: CI + 人 担当: AI + bot 担当: 人 完了条件: 未決の判 断が残っていない。 完了条件: 型、Lint、 テストが通る。 完了条件: トリアー ジ後の指摘がゼロ 完了条件: 本番環境 で動作確認が完了 する。 完了条件: 外形監視 が出来ている。 完了条件: 3や5など で明らかになった見 落としがLintやskill に反映されている。 ここまでの4つ(言語、フレームワーク、ディレクトリ構成、Lint)を揃えたうえで回す Hono Conference 2026 40
  35. 04 フェーズ別の手順 / 1 設計 設計:意思決定は人間がする 担当 人 + AI(補助)

    IRBANKの実例 入力 難しい機能の設計は「これはもう実装だ」と言われるほど細かく書く。ス 要件、デザイン クリーニング機能は14章、見出し191個 出力 設計が未決のまま実装する箇所はコードにマーカーを残し、一覧で管理出 設計書(ファイル構成、API、エラー、テスト観 点、未決事項) 来るようにする。 完了条件 実装の前に、未決事項が片付いている。 小さく始めるなら:設計書の目次を1つ決めて、どの機能も同じ章立てで書く。 Hono Conference 2026 41
  36. 04 フェーズ別の手順 / 1 設計 設計例:スクリーニング機能 スクリーニング機能の設計書の目次(抜粋) 0.前提知識(読み手向け) 5.時系列での絞り込み 8.結果の埋め込み

    5.3保存の方針 8.5古い形式との互換 1.全体の構成 5.6性能の見積もり 8.10権限 2.テーブル設計 5.8過去にさかのぼる検証モード 0.4元データのDBとの使い分け 2.1〜2.3テーブルごとの定義 2.4項目の一覧とDBの対応 3.反映の流れ 3.2変更を検知する対象のテーブル 3.3処理ごとの責務の分け方 3.6バッチ処理の実装設計 4. API設計 4.3実行ロジック 4.7利用者の設定の保存 6.キャッシュの方針 6.3現在値のキャッシュ 6.5履歴のキャッシュを作らない理由 6.7アクセス集中への対策 6.8過去データの訂正への対応 6.9容量と費用の見積もり 7.数式による絞り込み 7.2数式の言語仕様 7.6安全性と性能の制限 9.ファイル構成 10.エラーケース 11.インフラ構成 11.3費用の見積もり 12.テスト方針 13.未決定事項 14.関連ドキュメント 全14章、約4,000行。コード例が49 か所 7.10数式の例(受け入れテスト用) Hono Conference 2026 43
  37. 04 フェーズ別の手順 / 2 実装 実装:コンテキストを絞り、迷わず書かせる 担当 AI IRBANKの実例 入力

    AGENTS.mdにはコマンド、構成、規約へのリンクだけを書く。 設計書、AGENTS.md、rules 出力 PR(コード、テスト、生成物) 完了条件 型、Lint、テスト、commit前のフック 機械で判定できるなら Lint に書く。判断が要るものは rules に書く。 対象ファイルを指定した rules は、そのファイルを触るときだけ読まれ る。指定のない rules は毎回読まれるので、数を絞る。 フロント専用やインフラ専用のskillなど、そのディレクトリで必要なskill だけ読ませる。 小さく始めるなら:プロンプトの文書を少なくし、規約はLintかrulesで表す。 Hono Conference 2026 44
  38. 04 フェーズ別の手順 / 3 検証 検証:書いたものが正しいと確かめる 担当 CI + AI

    + 人 IRBANKの実例 入力 型検査、Lint、テスト、ビルド、OpenAPIと生成物の差分、マイグレーションの 不変、依存の脆弱性、秘密情報がコードに出ていない事をCIが見る。全部通る までレビューに進まない。 PR 出力 指摘を全て解消したPR AIが重大な指摘だけに絞ってレビューし、別のAIが同じPRを独立にレビューす る。(GreptileとGeminiを使用している) 完了条件 レビューの指摘対応が完了している。 QAの観点を満たしている。 ドメインの重要性に応じて人間がレビューする事もある。 PR毎にpreview(E2E)環境作成し、本番相当の実データで検証を行う。E2Eは AIが差分からシナリオを提案し、人間がブラウザで検証する。 小さく始めるなら:コードを書いたAIとは別のAIにレビューさせる。 Hono Conference 2026 45
  39. 04 フェーズ別の手順 / 4 リリース リリース:確実に動く実装をリリースする 担当 CI + 人

    IRBANKの実例 入力 マージするとstagingに自動デプロイ。QA担当に検証を依頼し、実データ レビューが完了したPR で確認が取れたものだけ本番リリースに含める。 出力 AIのレビューとQAを通ったあとでも、最後に人が触る。ここは外してい 本番環境へのデプロイ、QA担当の確認が取れた 機能 ない。 完了条件 本番環境でQA担当が確認した。 小さく始めるなら:必須チェックを2つに絞り、stagingで人が確認してから出す。 Hono Conference 2026 46
  40. 04 フェーズ別の手順 / 5・6 運用と学習 運用と学習:見落としを仕組みにする 担当 AI + bot

    + 人 IRBANKの実例 入力 エラーが発生した場合は、エラー通知から監視botが起票し、AIが調査す エラー監視の通知、レビューの指摘 る。エラーは仕分けだけ / レポート / 修正の3つの処理に分類される。修 出力 正完了後はAIが仕様書を更新する。 修正案のdraft PR、新しいLintルールやskill 人のレビューで見つけた見落としも傾向化し、Lintやskillに反映する(自作 完了条件 Lintは6月17本 → いま34本) 同じ見落としが、次は仕組みで止まる。 小さく始めるなら:同じ指摘を2回したら、Lintルールかskillにする。 Hono Conference 2026 47
  41. 04 フェーズ別の手順 / 5・6 運用と学習 自分たちの学習ループ例 何が起きたか 原因 対策 リクエストボディのバリデーションが飛ばさ

    れる createRouteのbodyにrequired: trueが無いと、Content-Typeの 無いリクエストはZodを通らず、空のオブジェクトがハンドラに 渡る。 required: trueを付け忘れたらLintで止め る。生成したOpenAPIのJSON全体を読む テストも追加 ゲートウェイの応答からX-Request-Idが消え る c.header()は仮のヘッダ置き場に積むだけで、ハンドラが新しい Responseを返すと載らない。hono/corsの副作用で偶然残って いた。 Responseを組み立てる側で明示的に付け る。corsを載せないテストで固定 共有パッケージとアプリでHonoのバージョ ンがずれ、型が合わない Renovateがアプリだけ4.12.29に上げ、共有のエラーハンドラ (4.12.27)のContextと別物の型になり、app.onErrorで型エラー 全アプリと全パッケージで同じバージョ ンに固定(^を外す)。更新はグループでま とめて 固定長配列の制約がOpenAPIに出ない @hono/zod-openapiは配列の.length()をminItems / maxItems に変換しない(文字列の.length()は変換する) .min().max()に置き換え。設計書のコード 例も同じに直す。 どれもHonoのバグではなく、仕様を知らないと気づけない挙動。見つけたらカスタムLintかテストにする。 Hono Conference 2026 48
  42. 今日の流れ(再掲) 事業背景 01 IRBANK、なぜ今作り直すのか、何が難しいか、4月から今日まで に起きたこと 03 開発前に揃えるもの 05 やめたこと 07

    再現キット 言語、Hono、ファイルの置き場所、Lint アンチパターン5つ 始める順番と、そのまま写せる雛形 Hono Conference 2026 02 ハーネスとは 04 フェーズ別の手順 AIの外側に置く4種類の仕組みの定義 設計から学習までの6フェーズ ハーネスとは何だったのか 06 08 重心の変化、人は中身を分かっているのか、得られた速さ、一言 での総括 まとめ 持ち帰ってほしい3つ 49
  43. 05 やめたこと やめたこと:5つのアンチパターン やめたこと 起きたこと 代わりに むやみに定型の仕様書を量産する 4月末に始め、5月で約300ファイルに。機能が横断的になると 書式に収まらず、コードとずれた。 難しい機能だけ、人が細かく設計する。

    skillを増やし続ける skillの説明文は毎回AIのコンテキストに入る。使われていない 15件を削除した。 使うディレクトリの下に置き、必要なskillだけ 有効にする。 規約をプロンプトに書く 作業が長引くと、指示は抜け落ちる。 Lintに書く。 Lintの無効化を許す 行き詰まったAIが、無効化して先に進もうとする。 無効化を禁止し、例外は理由付きのマーカー で明示させる。 PRごとに重い検査を全部回す PRが1日50本を超え、CIの費用が月に約 $180余分にかかって いた。 重い検査はmainマージだけで回す。 Hono Conference 2026 50
  44. 今日の流れ(再掲) 事業背景 01 IRBANK、なぜ今作り直すのか、何が難しいか、4月から今日まで に起きたこと 03 開発前に揃えるもの 05 やめたこと 07

    再現キット 言語、Hono、ファイルの置き場所、Lint アンチパターン5つと、Honoでぶつかったこと5つ 始める順番と、そのまま写せる雛形 Hono Conference 2026 02 ハーネスとは 04 フェーズ別の手順 AIの外側に置く4種類の仕組みの定義 設計から学習までの6フェーズ ハーネスとは何だったのか 06 08 重心の変化、人は中身を分かっているのか、得られた速さ、一 言での総括 まとめ 持ち帰ってほしい3つ 51
  45. 06 ハーネスとは何だったのか 前半と後半で、重心が逆になった 4月末〜7月 8月〜 コンテキストを増やす コンテキストを減らし、機械的チェックと レビューを増やす ・画面のセクションごとに仕様書を生成 ・5月の1か月で設計書が約300ファイル

    ・skillも増やし続けた。 ・機能が横断的になるにつれ、仕様書がコードとずれた。 ・仕様書156セクション分と、使われていないskill 15件を 削除 ・入口の文書 AGENTS.md は短く保つ。 ・自作Lintを21本から34本に ・レビューとQAのskillを増やした。 Hono Conference 2026 52
  46. 06 ハーネスとは何だったのか よく聞かれること:人は中身を分かっているのか AIに書かせると、人がコードの中身を分からなくなる(認知負債)と言われる。IRBANKではそうなってい ない。 1 2 3 意思決定は人間 書き方が統一されており、読解

    コストが低い 重要箇所は人もレビューして いる Honoアプリ21個が同じ構造で、層の境 界はLintが固定。副業の4人も担当外の アプリをすぐ読んでレビューできる。 AIレビューに加え、重要な機能は人が 読む。 設計書で決め、未決はTODOマーカーで 追う。 コードを説明する文書は持たない。仕様書300ファイルは捨て、コードと生成物(OpenAPI、仕様サイト)を見れば分かるようにした。 Hono Conference 2026 53
  47. 06 ハーネスとは何だったのか 振り返り:IRBANKのハーネスの中身 コンテキスト 機械的チェック レビュー 再発防止 AIが読む文書 書いた時点で機械的に止める。 できたものを確かめる。

    ・入口の文書 AGENTS.md ・厳しいtsconfig ・AIによるレビュー 見落としを次のLintやskillに する。 ・ルール文書8本 ・自作Lint 34本 ・検証環境での動作確認 ・skill 42本 ・ファイルの置き場所の境界ル ール ・QA ・人が書く設計書 ・見落としの傾向をLint、 skill、rulesへ ・自作Lint: 現在34本 ・commit前とpush前のフック 最初に定義した4種類に、ここまでの話を当てはめるとこうなる Hono Conference 2026 54
  48. 06 ハーネスとは何だったのか 得られた爆速:リアーキは数日、顧客要望は即日 何があったか 何をしたか 本番反映まで ランキングがDBを直接読んでいて重い 事前に計算したデータを読む経路に変更(リアーキ) 2日 過去日データの事前計算が重い

    一番遅かった指標の計算を変更 2日 顧客要望:上場市場で絞り込みたい 条件を追加。同じ日に、APIで絞る方式から事前計算したラベルで絞 る方式に作り替え 当日 顧客要望:ランキングの前日比が小数で桁落ち 表示を小数1桁に修正 即時 どれも、人が判断し、AIが書き、機械的チェックとレビューを通して本番に出した Hono Conference 2026 55
  49. 06 ハーネスとは何だったのか Honoを選んで良かった Honoは軽量で、柔軟で、TypeScriptの強みを最大限に引き出する事が出来る。 正確に書かせるには、間違わない仕組みが必要 爆速で書かせるには、迷わない選択肢が必要 TypeScriptの強みを引き出す 書き方が1つに決まる createRouteとZodで、ルート定義1つから型推論、バリデーション、OpenAPI が出る。AIの間違いは実行前に型で落ち、画面の型まで1本でつながった。

    ルートの定義も、エラーの返し方も、テストの書き方も21アプリで同じ。 共通化 app.request()でサーバーを立てずに試せる。AIが書いて、試して、直すまで 自分で回し、人の前に出てくるときには直っていた。 認証、権限、ログの共通処理とエラーの書式を専用の関数に寄せられた。 「間違わない仕組み」は後から足したのではなく、フレームワークの中に最初から あった。 自分で確かめられる 「迷わない選択肢」は、書き方が1つに揃い、AIが自分で確かめられるこ とで生まれた。 得られたアウトカム 本格開始から4か月でβを公開することがで きた。 Hono Conference 2026 このプロダクトと開発体制が評価され、事業 を継続することができた。 アーキテクチャの組み替えは数日、顧客要望 は最短即日で本番に出せる。 56
  50. 今日の流れ(再掲) 事業背景 01 IRBANK、なぜ今作り直すのか、何が難しいか、4月から今日まで に起きたこと 03 開発前に揃えるもの 05 やめたこと 07

    再現キット 言語、Hono、ファイルの置き場所、Lint アンチパターン5つ 始める順番と、そのまま写せる雛形 Hono Conference 2026 02 ハーネスとは 04 フェーズ別の手順 AIの外側に置く4種類の仕組みの定義 設計から学習までの6フェーズ ハーネスとは何だったのか 06 08 重心の変化、人は中身を分かっているのか、得られた速さ、一言 での総括 まとめ 持ち帰ってほしい3つ 58
  51. 07 再現キット 再現キット:始める順番 Step1 Step2 Step3 □ TypeScriptとHonoを入れる。 □ ルートをcreateRouteで書き、required:

    trueの付け忘れをLintで止める。 □ 設計書の目次を決め、未決事項をマーカ ーで追う。 □ OpenAPIからフロントの型を生成し、再 □ 規約を、AGENTS.md とルール文書とLint 生成漏れをCIで落とす。 に振り分ける。 □ 書いたAIとは別のAIにレビューさせる。 □ AGENTS.md を書く。 □ 新しいルートにはapp.request()のテスト を付ける。 □ commit前のフックで、型付きのLintとフ ォーマットを走らせる。 □ エラーレスポンスの書式を共有のハンド ラで1つにする。 □ tsconfigの3設定と、anyを禁止するLintを 入れる。 □ ファイルの置き場所をLintの境界ルール で決める。 Hono Conference 2026 □ 同じ指摘を2回したら、Lintルールかskill にする。 59
  52. 07 再現キット 再現キット:雛形3つ AGENTS.md コンテキスト AIが最初に読む文書。コマンド、構成、規約 へのリンクだけを書き、200行以内に保つ。 # コマンド #

    モノレポの構成 # TypeScript と Lint の設定 # Git フック # skill の置き場所 # 規約 → ルール文書へのリンク 使い方:細かい規約はここに書かない。ルー ル文書かLintへ 自作Lintルールの3 点セット 機械的チェック / 再発防止 ルール1本につき、実装、テスト、説明文書 をセットで置く。 lint-rules/ rule-name.mjs # 実装 rule-name.test.mjs # テスト rule-name.md # なぜ / 違反例 / 直し方 使い方:同じ指摘を2回したら、この3ファイ ルを足す。 設計書の目次 コンテキスト 人が判断を全部書く文書。どの機能も同じ章 立てにする。 0. 前提知識 1. 全体の構成 2. データ設計 3. 処理の流れ 4. API 設計 5. キャッシュと性能 6. ファイル構成 7. エラーケース 8. テスト方針 9. 未決事項 使い方:9の未決事項が解決したら実装担当 のAIに渡す。 Hono Conference 2026 60
  53. 今日の流れ(再掲) 事業背景 01 IRBANK、なぜ今作り直すのか、何が難しいか、4月から今日まで に起きたこと 03 開発前に揃えるもの 05 やめたこと 07

    再現キット 言語、Hono、ファイルの置き場所、Lint アンチパターン5つ 始める順番と、そのまま写せる雛形 Hono Conference 2026 02 ハーネスとは 04 フェーズ別の手順 AIの外側に置く4種類の仕組みの定義 設計から学習までの6フェーズ ハーネスとは何だったのか 06 08 重心の変化、人は中身を分かっているのか、得られた速さ、一言 での総括 まとめ 持ち帰ってほしい3つ 61