本文へ移動
Matsuba Inside

技術評価

業務ファイル共有基盤「松葉」の技術を評価軸ごとに 5 段階で評価し、根拠を添えたレポートです。

評価日
対象
 時点のソースコードと開発の記録
評価者
生成 AI（Claude Code）。開発者の依頼でソースコードと開発の記録を解析
位置づけ
第三者機関による評価ではありません

要旨

9 軸が ★4 以上（設計・データ・機能・クラウド・文書は ★5）です。改善余地は CI の失敗で取り込みを止めること、依存の更新の継続、アクセシビリティの検査記録の公開、脅威モデルの文書化です。

評価軸ごとの点数のレーダーチャート12 本の軸を 5 点満点で示します。点数は図に続く一覧にあります。123456789101112
  1. 1技術選定標準5 点中 3 点
  2. 2設計・保守性先進5 点中 5 点
  3. 3データ設計先進5 点中 5 点
  4. 4実装機能先進5 点中 5 点
  5. 5UI・UX・デザイン上位5 点中 4 点
  6. 6セキュリティ上位5 点中 4 点
  7. 7自動テスト標準5 点中 3 点
  8. 8CI/CD標準5 点中 3 点
  9. 9クラウド構成と運用先進5 点中 5 点
  10. 10ドキュメント先進5 点中 5 点
  11. 11開発プロセス上位5 点中 4 点
  12. 12生成 AI の活用上位5 点中 4 点
評価軸ごとの点数（5 点満点）。番号はレーダーの頂点に対応します。破線の環は ★3（一般的な水準）です。

1.評価の要点

すべての軸が基準の段（★3）以上です。自動テストと CI/CD が ★4 に届かなかった共通の理由は、CI の失敗が取り込み（マージ）を機械的に止める設定が無いことです（実際に CI の完了前や失敗のままの取り込みの記録があります）。CI/CD は、外部のアクションをコミットのハッシュに固定することも残ります。技術選定が ★3 に留まったのは、対象時点までに依存の自動更新の取り込みが止まった期間があり、脆弱性の通知もまとめて是正していて、更新と手当てが仕組みとして継続的に回っているとは言えないためです。★4 に留まった 4 つの軸で ★5 に向けて残った条件は、主に記録と開示です。アクセシビリティの検査の記録の公開とアクセシビリティの規則を機械的に強制する範囲の拡張、OWASP ASVS のレベル 2 の要件に対応づけた検証の記録と脅威モデルの文書、見積りと実績の比較を含む振り返り、生成 AI の活用の限界の開示が残っています。

1.1強み

  • 設計の規約そのものを自動テストとして実行し、層の越境やデータベースの入口の誤用を機械的に検出しています（設計・保守性、自動テスト）。
  • 認可はデータベース側の行レベルセキュリティを中核に置き、利用者の役割ごとにテーブルと操作の可否を確かめる専用のテストを、実際のデータベースで実行しています（データ設計、セキュリティ）。
  • Cloud Run の実行設定とスケジューラ・監視の設定はコードの宣言から実機へ反映し、デプロイ後と日次の検査で宣言との差分を機械的に検知しています（CI/CD、クラウド構成と運用）。
  • 文書の記述を実装から導いた値と機械的に照合し、要件・機能・画面の ID で文書から実装へ辿れます（ドキュメント）。
  • 社外との共有と受け取り、ウイルス検査、保持と削除、監査といった業務ドメインの要件を、運用者向けの監視・異常検知・設定まで含めて製品の一部として実装しています（実装機能）。

1.2改善余地

  • CI の失敗が取り込みを機械的に止める設定（必須チェック）と、本番へのデプロイが CI の完了を待つ仕組みです（自動テスト、CI/CD）。
  • 依存の更新と脆弱性の手当てが途切れずに回る運用（CI での脆弱性の自動検査・取り込みの期限）、中核の実行基盤・データストア・認証基盤の代替案を比べた記録と判断記録の書式（ADR の形）、外部の GitHub Actions をタグではなくコミットのハッシュで固定することです（技術選定、CI/CD、ドキュメント）。
  • WCAG 2.2 のレベル AA の項目を検査した記録の公開、アクセシビリティの規則を機械的に強制する範囲の拡張、描画した画面を走査する自動のアクセシビリティ検査（axe など）の導入です（UI・UX・デザイン）。
  • OWASP ASVS のレベル 2 の要件に対応づけた検証の記録と、資産・信頼境界・脅威を 1 つにまとめた脅威モデルの文書です（セキュリティ）。
  • 見積りと実績の比較を含む振り返りとその結果による手順の改善の記録、生成 AI の活用の限界（誤りの傾向、反証で退けた指摘、検証の往復の負担）の開示と人がコードの差分を読む範囲の定めです（開発プロセス、生成 AI の活用）。

目次へ

2.評価方法

評価者
開発者本人の依頼で、生成 AI（Claude Code）がソースコード・設定・開発の記録を解析して評価しました。
根拠
公開されている指針を参考に評価軸ごとの 5 段階の基準を先に定め、事実（コード・設定・数値）を基準に照らして採点しました。根拠には本サイト内の図・資料・数値へのリンクを添えています。
時点
 時点のソースコードと開発の記録を対象に、 に評価しました。
位置づけ
第三者機関による評価ではありません。プロジェクト概要のスライドでは扱っていない、技術と市場の 2 つの観点からの評価です。

基準を定めるにあたり、観点の整理には品質モデルの国際規格 ISO/IEC 25010[1]を参照し、段を持つ指針として、セキュリティは OWASP ASVS[2]の、アクセシビリティは WCAG 2.2[3]のレベルを尺度の目盛りとして借りています。指針の段を借りるのは目盛りとしてであり、適合や取得した認証を主張するものではありません。軸ごとに参照した指針の全件は付録の表にまとめています。

尺度の基準点は、一般的な業務システム開発チームが通常満たす水準（★3）です。★3 から ★5 は累積で、★n を付けるには ★3 から ★n までの条件をすべて満たす必要があります。1 人で開発した事実は次の節で数値として示し、採点には補正を入れていません。改善余地は各軸に必ず書き、★5 に届かない軸では次の段に上がるために満たしていない条件を、★5 の軸では維持と拡張の観点を述べています。

評価には限界があります。★3 は公開の指針が基本と位置づける実践で定めた段であり、実在するチームの平均を測ったものではありません。根拠は対象時点のソースコード・設定・記録の読み取りで確かめたもので、支援技術での操作、実行時の設定の確認、通知の実動といった実行時の試験と、脆弱性診断のような第三者の検査は含みません。テストの網羅率などの数値のしきい値は基準に置いていません。公開の資料も一律の目標を避けるよう述べています[4]。

実装機能・ドキュメント・生成 AI の活用の 3 軸は、段を定めた公開の標準が無く、公開の資料の実践を積み上げた本レポートの定義です。生成 AI の活用の軸は評価者と同じ生成 AI の利用を評価するもので、提供元の資料は実践の一覧として使い、効果の証拠にはしていません。採点では根拠の台帳を共有し、最初の採点を見せない生成 AI の別のインスタンス（別の会話）が条件ごとに独立に判定しました。さらに別のインスタンスが 2 つの判定を突き合わせ、食い違いと「満たさない」とした条件を対象時点のソースコードで直接確かめ直しています。条件の読み方が分かれた点は、評価者の推奨を開発者が確認して確定しています。

★の尺度

  1. 5先進

    業界の先進的な実践を体系的に備え、他者が参照できる水準です。公開の指針の基本より上の段に相当する実践を備えます。

  2. 4上位

    標準的な実践に加えて、経験豊富なチームが備える実践が複数あります。

  3. 3標準

    一般的な業務システム開発チームが通常満たす水準です。公開の指針の基本の段に相当する実践を備えます。

  4. 2一部不足

    標準的な実践に欠けがあり、運用や変更で支障が出うる状態です。

  5. 1不足

    基本的な実践が欠けています。

評価軸と観点

  1. 1技術選定

    業界標準との整合、市場価値、選定の一貫性と依存の管理

  2. 2設計・保守性

    構造の統一性、変更容易性、可読性、性能上の要所への配慮と、規約が守られ続ける仕組み

  3. 3データ設計

    スキーマの整合性と正規化、アクセス制御、検索・履歴・分割・移行の設計

  4. 4実装機能

    機能の広さと深さ、業務ドメインの要件の反映、例外系と管理機能の充実

  5. 5UI・UX・デザイン

    デザインシステムによる統一感、操作の一貫性、アクセシビリティ、応答性

  6. 6セキュリティ

    認証・認可、多層防御、機密情報の扱い、脅威への備え

  7. 7自動テスト

    テストの層と範囲、実環境相当の検証、CI での実行と保守性

  8. 8CI/CD

    自動化の範囲、デプロイの安全性と再現性、鍵と権限の扱い

  9. 9クラウド構成と運用

    サービス選定と疎結合、負荷に応じた拡張、観測性、構成の管理と差分の検知、運用の負荷と費用の均衡

  10. 10ドキュメント

    設計・運用・利用者向けの文書の網羅と鮮度、図による説明、実装との一致

  11. 11開発プロセス

    要件からデプロイまでの工程の網羅、成果物と判断の記録、検証の仕組み

  12. 12生成 AI の活用

    生成 AI を開発に組み込む方法の体系化、品質を人と仕組みで担保する運用、活用の透明性

目次へ

3.規模と体制

画面
68
API エンドポイント
375
テーブル
61
バックグラウンドジョブ
30
テストファイル
1,582
コード行数
835,979
工数
727時間
開発期間
4か月

2026-09-17 時点

松葉は、1 人の開発者が要件分析・設計・実装・テスト・デプロイ・資料作成のすべての工程を担当して作りました。開発期間は 4 か月、記録した作業時間は 727 時間です。開発には生成 AI（Claude Code）を全工程で活用しており、その方法と品質の担保は生成 AI の活用の軸で評価しています。

ソースコードは 1 つのリポジトリにまとめ、アプリケーションが 5 つ、共有パッケージが 12 個あります。画面と API は TypeScript、ファイルの検査と外部ストレージへの同期は Go で書き、データベースの構造は 79 本のマイグレーションで管理しています。実装は 10 段階に分け、各段階の下の作業単位ごとに計画と作業記録を残し、大半の作業単位では仕様も残しています。

作業時間の工程別の内訳は付録の作業時間の表に、言語別・領域別のコード行数はコード行数の表にあります。

目次へ

4.評価軸ごとの評価

以下のカードは、軸名と観点、★と段の名前、この点数の基準、要約、根拠、改善余地の順に並びます。

4.1技術選定

観点：業界標準との整合、市場価値、選定の一貫性と依存の管理

標準

この点数の基準：業界で広く採用される技術をサポート期間内の版で一貫して使い、依存の版が固定され、選定の理由が文書に残っています。

Next.js・Node.js・Go・PostgreSQL をサポート期間内の版で使い、同じ役割の技術を重複させず、依存は lockfile で固定して選定の理由を文書に残しています。自動更新は設定していますが取り込みが止まった期間があり、脆弱性の通知はまとめて是正しています。

根拠

  • 画面・API・非同期処理・データ層・認証の各分類で主要な技術が役割ごとに 1 つに絞られ、公式のサポート方針を持つ Next.js・Node.js・Go・PostgreSQL はその期間内の版です  使用技術の全体像
  • 依存は lockfile で固定し、更新の提案は週次で自動で届き、セキュリティ通知を週次で点検する手順を持ちます  使用技術の CI/CD
  • 画面と API は同じ Zod スキーマを共有し、データベースの列挙型とイベント契約から型を派生させ、生成物の差分を CI で検査します  アプリケーション・アーキテクチャ図
  • 基本構想の資料に、根幹となる技術の選定理由と、採用しなかった技術とその理由が記されています  資料「基本構想」

改善余地

依存の自動更新の取り込みが数週間止まった期間が対象時点までに 2 回あり、CI に脆弱性の自動検査がありません（週次の点検の手順は対象時点の直前に整えたものです）。依存の更新と脆弱性の手当てが途切れずに回る仕組み（CI での自動検査や、更新を取り込む期限の運用など）が次の段の条件です。

4.2設計・保守性

観点：構造の統一性、変更容易性、可読性、性能上の要所への配慮と、規約が守られ続ける仕組み

先進

この点数の基準：設計の規約そのものを自動テストとして実行し、副作用の分離や整合性の担保といった横断的な関心を共通の型と仕組みで強制しています。

バックエンド 4 層と機能単位のフロントエンドの配置を文書で定め、層の越境とデータベースの入口の誤用を ESLint と規約テストで検出します。API とサービス間のイベントの契約はスキーマから生成して差分を検査し、副作用の分離と整合性の担保を共通の仕組みで強制しています。

根拠

  • バックエンドは 4 層の責務と依存の方向を文書で定め、層をまたぐ import と、データベースへの 3 つの入口（利用者・共有リンクの受取人・システム）の使い分けを ESLint の規則で制限しています  設計ルール図（バックエンド）
  • API の定義（OpenAPI）は各ルートの Zod の定義から生成してコミットし、サービス間のイベントのメッセージ定義は Protocol Buffers から TypeScript と Go の型を生成して、コミットする生成物は CI が作り直して差分を検査します  アプリケーション・アーキテクチャ図
  • 設計の規約を機械的に確かめるテストが 78 本あり、検査の対象を手書きの一覧で持たずにコードを走査して導き出すことを、テストの書き方の規約にしています  数え方：規約テスト
  • 重い処理（ウイルス検査・サムネイル生成・外部ストレージへの同期・通知の配送）は送信予定表（Outbox）と Pub/Sub、別サービス、ジョブへ非同期化しています  システム全体構成図（詳細）

改善余地

送信予定表に書くイベントの種類と内容の型付け、通知系のイベントの契約の生成、フロントエンドの層の順序の機械検査、1 回の処理で発行するクエリの数（N+1 問題）の自動検出が拡張の余地です。規約テストの多くはリポジトリ変数と変更の範囲で起動が決まるジョブで走り、毎回走るジョブで名指ししているのは一部なので、その範囲を広げることも課題です。

4.3データ設計

観点：スキーマの整合性と正規化、アクセス制御、検索・履歴・分割・移行の設計

先進

この点数の基準：アクセス制御の規則を自動テストで検証し、スキーマ定義から型や列挙を派生させて実装との乖離を防ぎ、データの流れが図として文書化されています。

61 のテーブルを Prisma のスキーマと 79 本のマイグレーションで管理し、制約と索引を要件に対応させています。アクセス制御は行レベルセキュリティを中核にして実データベースへのテストで検証し、追記専用の監査ログを備え、型と列挙はスキーマから派生させています。

根拠

  • すべてのテーブルに主キーがあり、一意制約・CHECK 制約・部分インデックスで業務の規則をスキーマに表現しています  ER 図（詳細）
  • 行レベルセキュリティのポリシーが 103 本あり、有効にしたテーブルのうちポリシーを持たないテーブルは、利用者の接続からは全行を拒否します  ER 図（全体俯瞰）
  • アクセス制御の規則は、利用者の役割ごとにテーブルと操作の可否を確かめる専用のテストレーンで、実際の PostgreSQL に対して検証します  設計ルール図（データベース）
  • スキーマの列挙型から型を派生させて実装との乖離を防ぎ、データベース全体の形と流れを ER 図とデータアーキテクチャ図で示しています  データアーキテクチャ図

改善余地

設計ルールの「すべての外部キーに索引」に対して索引を持たない外部キーが一部に残り、網羅を確かめる検査がありません。全テーブルの行レベルセキュリティの有効・無効と、全ポリシーの命名と対象ロールの規約を、一覧と照合して固定する検査と、アクセス記録の保持と分割の設計が拡張の余地です。

4.4実装機能

観点：機能の広さと深さ、業務ドメインの要件の反映、例外系と管理機能の充実

先進

この点数の基準：機能どうしが一貫した概念モデル（権限・ライフサイクル・イベント）の上に組まれ、運用者向けの機能（監視・異常検知・設定）まで製品の一部として作り込まれています。

共有スペース（Box）の作成から社外との共有と受け取り、ウイルス検査、Google ドライブへの同期、保持と削除までを実装し、権限・失敗・上限の例外系、監視・設定の管理機能を備えます。ヘルプと通知を機能に対応づけ、機能は権限・ライフサイクル・イベントの共通の語彙で組んでいます。

根拠

  • 画面 68・API エンドポイント 375・バックグラウンドジョブ 30 で、要件の各分野に対応する機能と画面があります  プロジェクト概要のスライド
  • 権限は役割ごとの許可の一覧を画面・API・認証で共有し、行レベルセキュリティが同じ役割の区分をデータベース側にも重ね、権限の無い対象を「存在しない」として返す扱いと、無効化した Box の読み取り専用を共通の仕組みで行います  セキュリティ・認可アーキテクチャ図
  • 利用者向けのヘルプ記事 95 本が機能一覧と画面一覧の全件を覆うことを CI で検査しています  数え方：ヘルプ記事
  • 運用者向けに、監視のダッシュボード、異常検知のアラートとその対処ガイド、設定、利用状況の画面を製品に組み込んでいます  資料「管理と運用のしくみ」

改善余地

例外系と通知のうち、Box や利用者ごとの保存容量の上限の強制と、共有リンクの期限切れや上限到達を発行者へ知らせる通知、ファイルやフォルダを自動削除から守る保持（HOLD）の設定やアーカイブをメンバーへ知らせる通知がまだ無く、イベントの内容をスキーマで宣言しているのは一部のイベントに限られます。

4.5UI・UX・デザイン

観点：デザインシステムによる統一感、操作の一貫性、アクセシビリティ、応答性

上位

この点数の基準：WCAG 2.2 のレベル AA を目標にした実装と検査（コントラスト・フォーカスの可視化・状態の通知）が工程に組み込まれ、読み込み・空・エラーの状態の設計と応答性への配慮があります。

デザイントークンと共通部品で統一し、WCAG 2.2 のレベル A の主な達成基準に沿って実装しています。レベル AA を目標にした検査（コントラストの実測、フォーカスと読み上げの規約テスト）を工程に組み込み、読み込み・空・エラーの状態とゴミ箱や「元に戻す」での回復を備えます。

根拠

  • デザインシステムの文書が色・書体・角丸・余白の値を定め、実装のトークンと一致しています  デザインシステムのページ
  • フォーカスの二重リングと読み上げ領域の構造を規約テストで守り、要素ごとの上書きを機械的に止めています  使用技術の静的解析
  • 読み込み・空・エラーの状態を共通の部品と Suspense・エラーの境界で描き、ファイルやフォルダの削除はゴミ箱と「元に戻す」で回復できます  プロジェクト概要のスライド
  • ファイル本体はブラウザからストレージへ直接転送し、画面は静的なシェルを先に配ることで応答性に配慮しています  ファイルライフサイクル図

改善余地

レベル AA の達成基準を検査した記録（達成基準ごとの結果の表）が公開されておらず、規則の機械的な強制も入力欄の枠のコントラスト・条件つきで現れるライブリージョン・押せる範囲の寸法などで一部に留まります。レベル A でもワンタイムコードの自動送信の予告と、1 文字のショートカットを利用者が無効にできる手段が未対応で、描画した画面を走査する自動検査（axe など）の導入が改善余地です。

4.6セキュリティ

観点：認証・認可、多層防御、機密情報の扱い、脅威への備え

上位

この点数の基準：レベル 2 の主要な章を意識した実践（多要素認証・セッションと権限の細かな制御・データベース側のアクセス制御・監査ログ・依存の脆弱性対応）があります。

OWASP ASVS のレベル 1 の要件に沿って実装し、CSP と機密情報の専用管理を備えます。社外利用者の多要素認証、セッション制御、行レベルセキュリティ、追記専用の監査ログ、依存の脆弱性の是正があり、生成 AI による認証・認可の自己点検の記録を残しています。

根拠

  • 共有スペース（Box）の中のリソースへの認可は、サーバ側と行レベルセキュリティのポリシー 103 本の二重で確認し、未認証の利用者が参照できるテーブルと列を必要なものに限っています  セキュリティ・認可アーキテクチャ図
  • 社外の利用者にはメールによるワンタイムコードの多要素認証を必須にし、セッションと信頼済み端末を本人と管理者が失効できます  使用技術の認証・認可
  • アップロードしたファイルは未検査のバケットでウイルス検査を受けてから検査済みか隔離のバケットへ移り、月次でテスト用の検体（EICAR のテストファイル）を流して検査の経路を自己診断しています  資料「アップロードファイルのウイルススキャン」
  • 機密情報は専用の管理サービスに置き、CI は鍵ファイルを持たない認証を使い、デプロイ後に機密情報の出所を検査します  Google Cloud サービス構成図

改善余地

OWASP ASVS のレベル 2 の要件に対応づけた検証の記録と、資産・信頼境界・脅威を 1 つにまとめた脅威モデルの文書が無く、自己点検は認証・認可の範囲に限られます。応答ヘッダの一部（X-Content-Type-Options の nosniff・Referrer-Policy）、パスワードの規則の見直し（頻出パスワードとの照合）、静的解析によるセキュリティ検査も改善余地です。

4.7自動テスト

観点：テストの層と範囲、実環境相当の検証、CI での実行と保守性

標準

この点数の基準：単体テストと結合テストが主要な機能を覆い、変更ごとに CI で実行されます。

単体・実データベースの結合・行レベルセキュリティ・性能・E2E・規約の層を目的別に分け、Pull Request の変更の範囲に応じて CI で実行し、モックを原則使わない方針を定めています。失敗が取り込みを止める設定は無く、CI の完了前や失敗のままの取り込みの記録があります。

根拠

  • CI では本番と同じ全文検索拡張を同梱したデータベースを起動し、マイグレーションとアクセス制御の定義を本番と同じ順に適用してから結合テストを走らせます  使用技術のテスト
  • テストファイルは 1582 本で、単体（TypeScript と Go）・結合・行レベルセキュリティ・性能・E2E の層に分かれています  数え方：テストファイル
  • 設計の規約を機械的に確かめるテスト 78 本と、アクセス制御と性能の専用レーンを目的別に持ちます  数え方：規約テスト
  • モックを原則使わない方針と、モックの代わりに使う代替の一覧を文書化し、不安定なテストは隔離して根本原因を直してから戻す運用を定めています  使用技術のテスト

改善余地

取り込みを機械的に止める設定（必須チェック）が無く、CI の完了前や失敗のままの取り込みが繰り返されて欠陥が本番へ出た例もあり、失敗が取り込みを止めることが次の段の条件です。E2E と実環境相当の結合、目的別のレーン、方針の文書化、実行時間と不安定さの管理といった上の段の条件は満たしており、この 1 点が段を分けています。

4.8CI/CD

観点：自動化の範囲、デプロイの安全性と再現性、鍵と権限の扱い

標準

この点数の基準：CI の検査とビルドが変更ごとに自動で走り、パイプラインの定義がバージョン管理され、本番へのデプロイも同じ自動化された経路で行われます。

検証とデプロイのワークフローを分け、変更のあったサービスだけを本番へデプロイし、鍵レスの認証、依存の自動更新、デプロイ後の宣言との照合を備え、マイグレーションは設計上手動で適用します。ただし CI の結果は取り込みの条件ではなく、デプロイも CI の完了を待ちません。

根拠

  • 画面側のデプロイは同じ変更の API 側のデプロイの完了を待ち、新しい画面が古い API に当たらない順序にしています  CI/CD パイプライン図
  • 鍵ファイルを使わず Workload Identity Federation で認証し、GitHub に本番のデータベースの接続情報を置かず、CI はテスト用の使い捨てのデータベースだけを使います  Google Cloud サービス構成図
  • デプロイのたびに実行設定と機密情報の出所を実機から読み戻して宣言と照合し、API のデプロイ後にはスケジューラと監視の設定も宣言どおりに揃ったことを検査します  CI/CD パイプライン図
  • 生成物の差分検査はリポジトリ変数や変更の範囲に左右されず毎回走るジョブに置き、依存の更新は週次に届く自動の提案を取り込む形です  使用技術の CI/CD

改善余地

取り込みを機械的に止める設定（必須チェック）が無く、本番へのデプロイも CI の完了を待たないため失敗のままの変更がデプロイされた例があります。CI の結果が取り込みとデプロイの条件になることと、GitHub Actions の外部のアクションをメジャー版のタグではなくコミットのハッシュに固定することが次の段の条件で、その上の段のデプロイ後の検証・ロールバックの手順・定義の再利用は既に備えています。

4.9クラウド構成と運用

観点：サービス選定と疎結合、負荷に応じた拡張、観測性、構成の管理と差分の検知、運用の負荷と費用の均衡

先進

この点数の基準：宣言と実機の差分を機械的に検知し、アプリケーション側のアラートと保持・削除の運用が自動化され、サービスレベル目標と障害時の手順、費用と運用負荷の判断が文書化されています。

Cloud Run を中心にマネージドサービスを用途別に使い、非同期処理を Pub/Sub で疎結合にしています。専用のサービスアカウント、宣言と実機の日次の照合、アラートと保持・削除の自動化を備え、サービスレベル目標の目標値・障害時の手順・費用の判断を文書にしています。

根拠

  • 実行基盤は Cloud Run のサービスとジョブで、ストレージ・メッセージング・スケジューリング・シークレット・観測の各マネージドサービスを用途ごとに使い分けています  使用技術の Google Cloud
  • 業務のトランザクションで確定するイベントは送信予定表（Outbox）を経由して Pub/Sub で配信し、すべてのトピックにデッドレタートピックとその購読を対で付けています  システム全体構成図（詳細）
  • スケジューラと監視の設定はコードの宣言から実機へ反映し、デプロイ後と日次の検査で宣言との差分を機械的に検知します  使用技術の観測性
  • サービスアカウントを用途ごとに分け、権限はリソース単位を基本にしてプロジェクト全体への付与を一部に絞り、鍵ファイルを発行していません  Google Cloud サービス構成図

改善余地

サービスレベル目標は目標値の表に留まり、指標の定義と計測、エラーバジェットがありません。復元演習の実施記録、障害の振り返り（ポストモーテム）の定型、障害の重大度の判定基準と、宣言との照合をバケットの設定や Pub/Sub 以外のリソースの IAM の設定へ広げることが拡張の余地です。

4.10ドキュメント

観点：設計・運用・利用者向けの文書の網羅と鮮度、図による説明、実装との一致

先進

この点数の基準：設計判断の記録（何を選び、何を選ばなかったか）が残り、文書から実装・テストへ辿れ、文書の鮮度や整合を機械的に確かめる仕組みがあります。

設計・実装の文書 343 本と利用者向けヘルプ記事 95 本を持ち、アーキテクチャ図と ER 図で全体を説明しています。執筆と置き場の規約を機械の検査で守り、文書の記述を実装から導いた値と照合し、要件 ID から実装へ辿れ、採らなかった案の理由を残しています。

根拠

  • 設計・実装の文書は 343 本で、基本構想・機能一覧・設計ルール・実装の計画と記録など 6 つの区分に分かれ、置き場と書き方の規約を持ちます  数え方：設計・実装の文書
  • アーキテクチャ図と ER 図の一式が全体を説明し、利用者向けのヘルプは製品に組み込まれています  アーキテクチャ図の一覧
  • 規約の自動検査の対象をコードの外にある文書にも広げ、CI で検査しています  設計ルール図（規約の機械的強制）
  • 要件・機能・画面の ID で文書から実装へ、置き場の規約で実装からテストへ辿れ、基本構想の資料には採用しなかった技術とその理由が残ります  資料「基本構想」

改善余地

README と図の説明は CI の検査の範囲外で、README の一部に開発用の環境の切り替えとマイグレーションの手順の古い記述が、図の索引に存在しない図への言及が残ります。採用しなかった技術の理由は基本構想にありますが、技術選定の判断を横断して残す置き場と書式（ADR = Architecture Decision Record の形）や中核の基盤の代替案を並べて比べた記録、要件からテストへの追跡の拡張、リンク切れの検査が拡張の余地です。

4.11開発プロセス

観点：要件からデプロイまでの工程の網羅、成果物と判断の記録、検証の仕組み

上位

この点数の基準：作業単位ごとに仕様・計画・実装・レビューの成果物が残り、判断の理由が追跡でき、完了条件を検証で確かめています。

要件確認からリリースまでを手順書に定め、作業単位ごとに計画と作業記録（大半は仕様とレビューの記録も）を残し、判断の理由・課題・作業時間を記録して完了条件を検証で確かめます。変更は Pull Request ごとに CI の検査を受けますが、失敗で取り込みを止める設定はありません。

根拠

  • 各工程の手順書が番号つきの手順と完了条件を持ち、作業単位の足場は雛形から生成します  資料「開発ワークフローの実践」
  • 変更は Pull Request 単位で取り込み、CI の検査を毎回受けます（失敗が取り込みを止める設定はありません）  CI/CD パイプライン図
  • 作業時間は工程別に記録され、開発期間 4 か月・工数 727 時間として集計されています  数え方：工数

改善余地

振り返りの定型が無く、見積りと実績の比較は月次の進捗報告のプロジェクト単位に留まります。見積りと実績の比較を含む振り返りを行い、その結果による手順の改善を記録することが次の段の条件です（例えば作業単位ごとの見積りを置けば比較の材料になります）。

4.12生成 AI の活用

観点：生成 AI を開発に組み込む方法の体系化、品質を人と仕組みで担保する運用、活用の透明性

上位

この点数の基準：プロジェクト固有の指示書・規約・スキルをバージョン管理してエージェントに与え、仕様の作成から実装・レビューまで工程ごとに役割を分けて使っています。

指示書・スキル・エージェント定義をバージョン管理し、仕様から実装・レビューまで役割を分けて生成 AI（Claude Code）を使っています。出力は別インスタンスの反復レビュー、開発者の設計判断と取り込みの承認、規約テスト・静的解析で確かめ、活用の方法は開発過程資料が示します。

根拠

  • プロジェクト固有のスキル 13 本と役割別のエージェント定義を指示書とともにリポジトリでバージョン管理し、工程ごとに仕様・実装・レビューの役割を分けています  数え方：エージェントのスキル
  • 実装を担うエージェントは曖昧な点を推測で埋めずに質問を返し、git への書き込み（コミットなど）は人の確認を経る終了時の手順でだけ行います  資料「開発ワークフローの実践」
  • レビューを担うエージェントはファイルを直さずに指摘だけを返し、指摘がゼロになるまで反復する運用で、仕様と実装のレビューの記録が大半の作業単位に残ります  資料「開発ワークフローの実践」
  • 生成 AI が書いたコードは、静的解析・型検査・規約テスト 78 本・生成物の差分検査を CI で受けます  数え方：規約テスト

改善余地

活用の方法は開発過程資料で示していますが、限界の記述は UI の実測を人の目視の代わりにしないといった一部に留まり、誤りの傾向、反証で退けた指摘、検証の往復の負担を読者向けに述べた記述がありません。人がコードの差分を読む範囲を定めることと、レビュー工程の外で行う修正（フィードバック対応や、複数の箇所にまたがる是正）にも別インスタンスのレビューを求める規則にすることも改善余地です。

目次へ

5.特筆すべき設計判断

5.13 つの境界の契約をスキーマから生成する

画面と API、サービス間のイベント、データベースの 3 つの境界で、契約を手で二重に書かない形にしています。画面と API は同じ検証スキーマを共有し、API の定義はルートごとに宣言した入出力の検証スキーマから生成してリポジトリにコミットし、CI が毎回作り直して差分があれば失敗させます。サービス間のイベントは Protocol Buffers の定義から TypeScript と Go の型を生成し、コミットする Go の生成物は同じ差分検査を通し、TypeScript の生成物はコミットせずビルドのたびに作り直します。データベースの列挙型はスキーマ定義から派生させ、値の直書きは静的解析が止めます。

画面と API が共有するのは検証スキーマの形と、両方が同じ値で合意していないと壊れる固定の定数です。管理者の設定や環境で変わる値は、画面と API を別々にデプロイする構成では片方だけが新しい瞬間があるため、共有せず応答で渡します。API の型をそのまま画面に共有する方式は採らず、型の共有は共有パッケージの検証スキーマで完結させています。この判断は技術選定と設計・保守性の根拠になっています。全体像はアプリケーション・アーキテクチャ図に、使用技術は API とモノレポの節にあります。

5.2データベース側の行レベルセキュリティを中核にした認可

認可の単位はテナントではなく共有スペース（Box）で、同じ利用者が複数の Box に別の役割で所属できます。役割ごとの許可の一覧は画面・API・認証基盤で 1 つを共有し、最後の層としてデータベースの行レベルセキュリティが同じ役割の区分を SQL で持ち、103 本のポリシーで読み書きの範囲を強制します。権限の無い行は拒否ではなく「存在しない」として返し、存在の有無を漏らさない形にしています。データベースへの入口は利用者・共有リンクの受取人・システムの 3 経路と認証基盤の専用口に絞り（監査ログの退避だけを理由つきの例外にし）、どのコードがどの入口を使えるかを静的解析（import の制限）で強制しています。

ポリシーには命名と対象ロールの明示の規約があり、専用のテストレーンが実際の PostgreSQL に本番と同じ順（マイグレーション、権限の定義、ポリシーの順）で定義を適用し、利用者の役割ごとにテーブルと操作の可否を検証します。データベースのマネージドサービスが提供する認証や REST の公開機能は使わず、自前のサービスだけがデータベースに接続します。認証基盤が利用者の文脈なしに読み書きする表は行レベルセキュリティの対象外とし、その理由を文書に残しています。図はセキュリティ・認可アーキテクチャ図、ER 図（全体俯瞰）とストレージ・データベース構成図、関係する軸はデータ設計とセキュリティです。

5.3送信予定表（Outbox）による副作用の分離

業務のトランザクションから、メール・メッセージング・タスクキュー・ストレージの操作・外部ストレージの同期といった外部への副作用を直接呼ばない規約を置いています。後から起きればよい副作用は、業務データの更新と同じトランザクションで送信予定表に書き、定期の送出ジョブが Pub/Sub へ配信し、各サービスが受け取ります。更新と通知の食い違いが起きず、失敗した行は再試行の上限で隔離して管理画面から再投入できます。受信側はイベントの ID で重複配信を無害化し（処理済みイベントの記録や一意制約）、メールの送信は前後を 2 つのトランザクションに分けて二重送信を防いでいます。

すべてのトピックにデッドレタートピックとその購読を対で付け、配信できなかったメッセージが無言で消えない形にしています。通知の宛先を決める判定も 1 か所に集めています。通知は 57 種類あり、宛先を解決する処理ごとに「配ってよい根拠」を型で宣言させています。認証メールの直送のような規約の例外は、理由つきで文書に明記しています。図はイベント駆動・通知配送図とシステム全体構成図（詳細）、関係する軸は設計・保守性とクラウド構成と運用です。

5.4宣言と実機の照合による構成管理

クラウドの構成は Infrastructure as Code のツール（Terraform など）を使わず、構築の手順書を正としたうえで、変わりやすい部分をコードで宣言して実機と照合しています。一部のリソースだけをツールに載せる形は、ツールと手作業の二重所有になってどちらを真実にするかが曖昧になるため採っていません。Cloud Run の実行設定と機密情報の注入はデプロイのワークフローが宣言し、デプロイのたびに実機から読み戻して宣言と一致すること、機密情報が Secret Manager 由来であることを確かめます。スケジューラと監視の設定はコードの台帳から生成した宣言をコミットし、PR の差分がそのまま変更の計画になり、デプロイ後に適用して差分が無くなったことを検査します。

デプロイは鍵ファイルを 1 本も発行せず、Workload Identity Federation でサービスアカウントを借りて行い、サービスを呼び出す経路（イベントの push・タスクの配送・内部のエンドポイント）は OIDC で認証します。宣言の外にあるリソースは確認項目つきの構築手順書で再現し、日次の検査ジョブが宣言と実機の差分をアプリ内のアラートとして知らせます。図は CI/CD パイプライン図と Google Cloud サービス構成図、使用技術は観測性の節、関係する軸は CI/CD とクラウド構成と運用です。

5.5アップロードの検査と隔離のライフサイクル

アップロードされたファイルは、未検査・検査済み・隔離の 3 段のバケットで扱います。ファイル本体はブラウザから署名付き URL でストレージへ直接転送し、保存の完了イベントを受けた検査サービスがウイルス検査を行い、結果に応じて検査済みか隔離へ移します。移動は「複製し、データベースで確定し、元を削除する」順に固定し、途中で失敗しても原本を失いません。利用者に見える現行版は検査が陰性になった最新の版だけで、差し替え中も旧版が使えます。

隔離バケットは「消せるが読めない」主体と「借用したときだけ読める」主体に分け、通常のダウンロードの経路からは隔離したファイルを取り出せない形にしています。利用者のファイルを解析するサムネイル生成サービスには、ストレージ・データベース・機密情報の権限を持たせていません。検査の経路はテスト用の検体（EICAR テストファイル）で月次に自己診断し、ウイルス定義ファイルの更新の失敗も異常として知らせます。図はファイルライフサイクル図と Google Cloud サービス構成図、資料は「アップロードファイルのウイルススキャン」、関係する軸はセキュリティと実装機能です。

5.6規約を機械に守らせる

設計の規約は文書とレビューだけに預けず、自動テストとしても実行しています。専用のディレクトリに置いた規約テストは 78 本あり（ほかにも同種の検査があります）、検査の対象を手書きの一覧で持たずにコードを走査して導き出すことと、検出が空振りしていないことをテストで確かめる（アサートする）ことを作り方の規約にし、多くの検査では検出器そのものにも陽性と陰性の見本を持たせています。規約テストの多くはリポジトリ変数と変更の範囲で起動が決まるジョブで走るため、そのジョブが走らない Pull Request でも守るべき検査は、毎回走るジョブで名指しして実行し、生成物の差分検査もそこに置いています。

同じ考え方を文書にも広げ、文書の記述（API のエンドポイント・画面のルート・トピック・メール送信用の DNS レコード）を実装から実行時に導いた値と照合する検査と、文書に経緯（変更の履歴）を書かない執筆規約の検査を CI で毎回走らせています。人の注意力に預けた規律が繰り返し崩れた経験から、規約と機械の検査を対で運用する形に至っています。図は設計ルール図、使用技術は静的解析の節、関係する軸は設計・保守性、ドキュメント、生成 AI の活用です。

目次へ

6.付録

6.1評価軸と参考にした指針

各軸の 5 段階の基準を定めるときに参照した公開の指針です。番号は出典の一覧に対応します。

軸参考にした指針
技術選定各技術の公式のサポート方針[5][6][7][8]、The Twelve-Factor App[9]、OpenSSF Scorecard の検査項目[10]
設計・保守性ISO/IEC 25010 の保守性[1]、DORA の Code maintainability[11]と Loosely coupled teams[12]、The Twelve-Factor App[9]
データ設計PostgreSQL 文書の制約の章[13]、DORA の Database change management[14]
実装機能ISO/IEC 25010 の機能適合性[1]
UI・UX・デザインWCAG 2.2[3]、ウェブアクセシビリティ導入ガイドブック[15]、Nielsen Norman Group のユーザビリティ・ヒューリスティック[16]
セキュリティOWASP ASVS とそのレベルの定義[2][17]、OWASP Top Ten[18]、Google Cloud Well-Architected Framework のセキュリティの柱[19]
自動テストSoftware Engineering at Google のテストの章[20]、DORA の Test automation[21]、Code Coverage Best Practices[4]
CI/CDDORA の Continuous integration[22]と Deployment automation[23]、GitHub Actions の Secure use reference[24]、OpenSSF Scorecard の検査項目[10]
クラウド構成と運用Google Cloud Well-Architected Framework[25]とその運用の柱[26]およびセキュリティの柱[19]、Site Reliability Engineering のサービスレベル目標と監視の章[27][28]、DORA の Monitoring and observability[29]
ドキュメントDiátaxis[30]、C4 model[31]、arc42[32]、Architecture decision records[33]、DORA の Documentation quality[34]
開発プロセスDORA の Working in small batches[35]、Trunk-based development[36]、Version control[37]、Streamlining change approval[38]
生成 AI の活用DORA AI Capabilities Model[39]と Clear and communicated AI stance[40]、Best practices for Claude Code[41]と Claude Code の Security[42]

6.25 段階の基準の全文

評価軸と 5 段階の基準

  1. 1

    技術選定

    業界標準との整合、市場価値、選定の一貫性と依存の管理

    1. 1

      不足 主要な技術の選定理由が説明できず、保守が止まった技術や互いに整合しない技術が中核にあります。

    2. 2

      一部不足 業界で一般的な技術を使っていますが、版が古い、または同じ役割の技術が重複するなど、一貫性に欠けがあります。

    3. 3

      標準 業界で広く採用される技術をサポート期間内の版で一貫して使い、依存の版が固定され、選定の理由が文書に残っています。（評価した段）

    4. 4

      上位 実行基盤とデータストアの選定が要件に対応づけて説明でき、依存の更新と脆弱性の手当てが仕組みとして継続的に回っています。

    5. 5

      先進 選定の理由と代替案の比較が記録され、型やスキーマを複数の層で共有するなど、技術どうしの結合が設計として一貫しています。

  2. 2

    設計・保守性

    構造の統一性、変更容易性、可読性、性能上の要所への配慮と、規約が守られ続ける仕組み

    1. 1

      不足 層や責務の分け方が定まっておらず、変更の影響範囲が読めません。

    2. 2

      一部不足 層の分け方はありますが、規約が文書やレビューに頼っていて、逸脱が残っています。

    3. 3

      標準 層と責務の分け方が定まり、命名と配置の規約が文書化され、静的解析と型検査が CI で守っています。

    4. 4

      上位 依存の方向や境界の越境を機械的に検査し、外部との契約（API・イベント）をスキーマから生成して実装との整合を保ち、性能の要所（問い合わせの数・重い処理の非同期化・キャッシュなど）に設計上の対処があります。

    5. 5

      先進 設計の規約そのものを自動テストとして実行し、副作用の分離や整合性の担保といった横断的な関心を共通の型と仕組みで強制しています。（評価した段）

  3. 3

    データ設計

    スキーマの整合性と正規化、アクセス制御、検索・履歴・分割・移行の設計

    1. 1

      不足 スキーマに整合性の制約（主キー・外部キー・NOT NULL）が欠け、変更が手作業です。

    2. 2

      一部不足 制約はありますが、スキーマの変更履歴が整っていない、または索引と検索の設計が後追いです。

    3. 3

      標準 正規化された関係スキーマをスキーマ定義（ORM か同等）とバージョン管理されたマイグレーションで管理し、制約と索引が要件に対応しています。

    4. 4

      上位 行レベルのアクセス制御か同等の仕組みをデータベース側で持ち、監査や履歴の要件に応じた設計（追記専用・分割）と、検索の要件に応じた設計（全文検索・索引）があります。

    5. 5

      先進 アクセス制御の規則を自動テストで検証し、スキーマ定義から型や列挙を派生させて実装との乖離を防ぎ、データの流れが図として文書化されています。（評価した段）

  4. 4

    実装機能

    機能の広さと深さ、業務ドメインの要件の反映、例外系と管理機能の充実

    1. 1

      不足 中核の機能だけで、例外系（失敗・権限なし・上限）の扱いが定まっていません。

    2. 2

      一部不足 主要な機能はそろっていますが、管理機能や例外系（権限・失敗・上限）に穴があります。

    3. 3

      標準 業務の主要な流れを一通り実装し、権限・失敗・上限などの例外系と管理機能を備えています。

    4. 4

      上位 業務ドメイン固有の要件（社外との共有・期限・検査・保持・監査など）を機能として実装し、利用者向けのヘルプと通知が機能に対応しています。

    5. 5

      先進 機能どうしが一貫した概念モデル（権限・ライフサイクル・イベント）の上に組まれ、運用者向けの機能（監視・異常検知・設定）まで製品の一部として作り込まれています。（評価した段）

  5. 5

    UI・UX・デザイン

    デザインシステムによる統一感、操作の一貫性、アクセシビリティ、応答性

    1. 1

      不足 画面ごとに見た目と操作が異なり、キーボード操作や支援技術への配慮がありません。

    2. 2

      一部不足 共通の部品はありますが、配色・余白・文言の規則が定まっておらず、アクセシビリティは一部の画面に限られます。

    3. 3

      標準 デザイントークンと共通部品で統一され、主要な画面が WCAG 2.2 のレベル A の達成基準（代替テキスト・キーボード操作・ラベル・エラーの特定など）に沿って実装され、状態の表示と誤操作からの回復が設計されています。

    4. 4

      上位 WCAG 2.2 のレベル AA を目標にした実装と検査（コントラスト・フォーカスの可視化・状態の通知）が工程に組み込まれ、読み込み・空・エラーの状態の設計と応答性への配慮があります。（評価した段）

    5. 5

      先進 レベル AA の達成基準を検査した記録が公開され、デザインシステムが文書化されて実装と一致し、アクセシビリティの規則が自動テストや規約で守られています。

  6. 6

    セキュリティ

    認証・認可、多層防御、機密情報の扱い、脅威への備え

    1. 1

      不足 認証はありますが、認可が画面側だけで、機密情報の管理や入力の検証が不十分です。

    2. 2

      一部不足 サーバ側で認可を確認していますが、入力の検証・セキュリティヘッダ・機密情報の専用の管理が一部に留まります。

    3. 3

      標準 OWASP ASVS のレベル 1 の要件に沿った実装があり、認可はサーバ側で確認され、入力の検証・セキュリティヘッダ・機密情報の専用の管理を備えています。

    4. 4

      上位 レベル 2 の主要な章を意識した実践（多要素認証・セッションと権限の細かな制御・データベース側のアクセス制御・監査ログ・依存の脆弱性対応）があります。（評価した段）

    5. 5

      先進 レベル 2 の要件を検証した記録と文書化した脅威モデルがあり、脅威に応じた専用の防御（アップロードの検査と隔離・署名付き URL・鍵レスの認証など）とセキュリティの検証（専用のテスト・定期的な自己診断）が自動化されています。

  7. 7

    自動テスト

    テストの層と範囲、実環境相当の検証、CI での実行と保守性

    1. 1

      不足 自動テストがほとんど無く、手作業の確認に頼っています。

    2. 2

      一部不足 単体テストはありますが、結合の層が無い、または CI で実行されていません。

    3. 3

      標準 単体テストと結合テストが主要な機能を覆い、変更ごとに CI で実行されます。（評価した段）

    4. 4

      上位 E2E テストと実環境相当の結合テスト（実データベース・ストレージの代替）があり、層ごとに目的が分けられ、失敗が取り込みを止めます。

    5. 5

      先進 性能・アクセス制御・規約など目的別の専用レーンを持ち、モックに頼らない検証方針が文書化され、実行時間と不安定さが管理されています。

  8. 8

    CI/CD

    自動化の範囲、デプロイの安全性と再現性、鍵と権限の扱い

    1. 1

      不足 ビルドとデプロイが手作業で、手順が人に依存しています。

    2. 2

      一部不足 CI で検査は回りますが、デプロイが手作業、または検査と同じ自動化された経路で行われていません。

    3. 3

      標準 CI の検査とビルドが変更ごとに自動で走り、パイプラインの定義がバージョン管理され、本番へのデプロイも同じ自動化された経路で行われます。（評価した段）

    4. 4

      上位 CI の結果が取り込みとデプロイの条件になり、サービスごとの独立したデプロイ、変更範囲に応じた実行、鍵レスの認証（OIDC）、依存とアクションの固定と自動更新があります。

    5. 5

      先進 デプロイ後の検証（設定と機密情報の出所の確認・実機と宣言の照合）が自動化され、ロールバックの手順が定められ、パイプラインの定義が再利用できる形に整理されています。

  9. 9

    クラウド構成と運用

    サービス選定と疎結合、負荷に応じた拡張、観測性、構成の管理と差分の検知、運用の負荷と費用の均衡

    1. 1

      不足 単一のサーバに手作業で配置し、ログや監視がありません。

    2. 2

      一部不足 マネージドサービスを使っていますが、構成が記録されず、監視は基盤の既定だけです。

    3. 3

      標準 マネージドの実行基盤・ストレージ・メッセージングを用途に応じて使い、構成を再現できる記録（IaC か同等の宣言）と、構造化ログと基本の監視・アラートがあります。

    4. 4

      上位 非同期処理の疎結合（キュー・イベント・再試行と失敗の隔離）、負荷に応じた実行基盤の拡張の設定、最小権限のサービスアカウント、機密情報の管理、環境の分離があります。

    5. 5

      先進 宣言と実機の差分を機械的に検知し、アプリケーション側のアラートと保持・削除の運用が自動化され、サービスレベル目標と障害時の手順、費用と運用負荷の判断が文書化されています。（評価した段）

  10. 10

    ドキュメント

    設計・運用・利用者向けの文書の網羅と鮮度、図による説明、実装との一致

    1. 1

      不足 README 程度で、設計や運用の文書がありません。

    2. 2

      一部不足 設計の文書はありますが、実装と乖離している、または利用者向け・運用向けの文書が欠けています。

    3. 3

      標準 手順書どおりに環境構築・実行・テスト・デプロイを再現でき、要件・設計・運用の文書と利用者向けの説明が実装の変更に追随して更新されています。

    4. 4

      上位 アーキテクチャ図や ER 図で全体を説明し、利用者向けのヘルプが製品に組み込まれ、文書の置き場と書き方の規約があります。

    5. 5

      先進 設計判断の記録（何を選び、何を選ばなかったか）が残り、文書から実装・テストへ辿れ、文書の鮮度や整合を機械的に確かめる仕組みがあります。（評価した段）

  11. 11

    開発プロセス

    要件からデプロイまでの工程の網羅、成果物と判断の記録、検証の仕組み

    1. 1

      不足 工程の区切りが無く、要件や設計の記録が残っていません。

    2. 2

      一部不足 工程は分かれていますが、仕様や計画が散在したメモに留まり、実績が記録されていません。

    3. 3

      標準 要件定義・設計・実装・テスト・リリースの工程があり、仕様と計画が文書化され、変更は自動の検証を経て小さな単位で取り込まれ、課題と作業時間が記録されています。

    4. 4

      上位 作業単位ごとに仕様・計画・実装・レビューの成果物が残り、判断の理由が追跡でき、完了条件を検証で確かめています。（評価した段）

    5. 5

      先進 工程の手順自体が再利用できる形（手順書・チェックリスト）に整理され、振り返り（見積りと実績の比較を含む）による手順の改善が記録されています。

  12. 12

    生成 AI の活用

    生成 AI を開発に組み込む方法の体系化、品質を人と仕組みで担保する運用、活用の透明性

    1. 1

      不足 生成 AI を使っていない、または使い方の記録が無く、出力をそのまま採用しています。

    2. 2

      一部不足 コードの補完や質問への利用に留まり、出力の検証が担当者の裁量に任されています。

    3. 3

      標準 生成 AI の利用の方針（任せる範囲・渡さない情報）を明文化し、出力を人がレビューし、自動テストと静的解析で品質を確かめています。

    4. 4

      上位 プロジェクト固有の指示書・規約・スキルをバージョン管理してエージェントに与え、仕様の作成から実装・レビューまで工程ごとに役割を分けて使っています。（評価した段）

    5. 5

      先進 別のインスタンスによるレビューや検証の反復と規約の機械的な強制を含む運用が体系化され、活用の方法と限界が読者に開示されています。

6.3作業時間

開発期間の工程別の作業時間（合計は「工数」の数値と同じ）

工程内訳時間
要件定義要件分析3.0
要件定義（資料作成を含む）8.5
類似サービス調査0.5
理解・仕様確認39.5
仕様検討（資料作成を含む）58.0
小計109.5
基盤設計・構築技術選定1.0
技術調査・検証6.5
基盤設計22.0
基盤開発28.5
環境構築（開発）25.5
小計83.5
データベース設計・実装データベース設計4.0
データベース実装10.5
小計14.5
バックエンドバックエンド設計12.5
バックエンド開発161.5
小計174.0
フロントエンドデザイン設計3.0
フロントエンド設計20.0
フロントエンド開発136.0
小計159.0
クラウド環境構築環境構築（クラウド）46.5
テストテスト設計・実装12.5
スモークテスト36.0
不具合調査・解消15.0
小計63.5
デプロイ・運用設計デプロイ8.0
ドキュメントマニュアル作成9.0
技術資料作成30.5
資料作成（利用者向け）17.0
資料整理6.5
小計63.0
進行管理ミーティング5.5
合計727.0

6.4コード行数

製品とテストの比

  • 製品 58%
  • テスト 42%

言語別のコード行数（製品・テスト・合計）

言語製品テスト合計
TypeScript300,478343,213643,691
TSX153,9410153,941
Go11,03911,20122,240
SQL5,68805,688
YAML3,864133,877
Prisma2,36102,361
CSS1,36401,364
JSON1,12701,127
JavaScript793110903
その他7870787
合計481,442354,537835,9795,855 ファイル

領域別のコード行数（製品・テスト・合計）

領域製品テスト合計
apps/api150,331218,507368,838
apps/web257,35396,962354,315
packages/shared29,08418,46747,551
apps/sync7,8648,74416,608
packages/database11,01518311,198
packages/help-content4,8273,0627,889
packages/email5,3421,8927,234
apps/scanner3,2432,3515,594
packages/auth4,2121,1385,350
.github3,19903,199
packages/help-search1,2771,7573,034
apps/thumbnailer1,2749602,234
packages/events9972841,281
その他1,4242301,654
合計481,442354,537835,9795,855 ファイル

6.5数え方

本文と数値のカード、根拠の行で使った数の名前・値・数え方です。

画面 68
Web アプリ（Next.js の App Router）の page.tsx の数（開発用のプレビュー画面を除く）
API エンドポイント 375
OpenAPI 定義のパスの数（HTTP メソッド別の操作は 402）
テーブル 61
Prisma スキーマの model 宣言の数
バックグラウンドジョブ 30
定期・随時に実行するジョブの登録数（定期 27・随時 3。独立した Go のサービス 2 本は含めない）
テストファイル 1,582
自動テストのファイル数（TypeScript の単体・結合テスト 1,491・E2E 58・Go 33）
コード行数 835,979
プログラム・テスト・設定のファイルの行数（TypeScript・Go・SQL など。文書と自動生成のファイルを除き、コメントを含め、空行を除く。製品のコード 481,442・テストのコード 354,537）
工数 727 時間
開発期間に工程別に記録した作業時間の合計（要件分析・設計・開発・テスト・資料作成など 27 項目）
開発期間 4 か月
要件分析の開始から実装の完了（テスト・デプロイを含む）までの月数（2026 年 5 月中旬〜⁠9 月中旬。端数は切り捨て）
アプリケーション 5
apps/ 直下のディレクトリ数（web・api・thumbnailer は Node.js、sync・scanner は Go）
共有パッケージ 12
packages/ 直下のディレクトリ数（pnpm のパッケージ 11・Go のモジュール 1）
マイグレーション 79
データベースのスキーマ変更のマイグレーションの数（マイグレーションのディレクトリの数。初回の作成から対象時点までの全件で、適用済みのものは書き換えない）
実装の段階 10
実装を分けた段階の数（環境構築・認証・ファイル共有の基盤・ファイルの拡張・信頼性・保持期間・管理画面と監査・公開ページ・アプリ内ヘルプ・リリース準備）。各段階の下に、計画と作業記録を残す細かな作業単位を持つ（大半は仕様とレビューの記録も持つ）
RLS ポリシー 103
データベースの行レベルセキュリティに宣言したポリシーの数（定義ファイルの CREATE POLICY 文をコメントを除いて数えた値）。行レベルセキュリティを有効にした表は 53、うちポリシーを持つ表は 48 で、認証基盤が利用者の文脈なしに読み書きする 8 表は対象外
通知の種類 57
利用者や管理者に知らせる通知の種類の数（通知テンプレートの識別子の数）。管理者が本文を編集できる 46 種と、認証に関わりコードに固定した 11 種の合計で、アプリ内だけで知らせる 5 種を含む。テーマや宛先による文面の分岐は数えない
規約テスト 78
設計の規約を機械的に確かめる自動テストのファイル数（規約テスト専用のディレクトリにあるもの。Web 72・API 6。専用のディレクトリの外〔共有パッケージや各アプリの単体テストの置き場〕にある同種のテストは含めない）
ヘルプ記事 95
アプリに組み込んだ利用者向けヘルプの記事の数（MDX。検査用の見本記事は含めない）。記事が機能一覧と画面一覧の全件を覆うことは CI で検査する
設計・実装の文書 343
リポジトリの docs 配下の Markdown 文書の数（基本構想 18・デザイン候補 2・機能一覧 37・ページ一覧 57・設計ルール 16・実装の計画と記録 213 の 6 区分。ヘルプ記事と開発過程資料は含めない）
エージェントのスキル 13
生成 AI のエージェント用にリポジトリで管理するスキルの数（領域の知識 6・工程の手順 6・資料デザイン 1。役割別のエージェントの定義 5 は別に数える）

6.6出典

  1. [1]

    ISO/IEC 25010:2023 Systems and software engineering — Systems and software Quality Requirements and Evaluation (SQuaRE) — Product quality model（新しいタブで開きます） ISO/IEC

    https://www.iso.org/standard/78176.html 2026-09-26 参照

  2. [2]

    OWASP Application Security Verification Standard (ASVS)（新しいタブで開きます） OWASP Foundation

    https://owasp.org/projects/asvs 2026-09-26 参照

  3. [3]

    Web Content Accessibility Guidelines (WCAG) 2.2（新しいタブで開きます） W3C

    https://www.w3.org/TR/WCAG22/ 2026-09-26 参照

  4. [4]

    Code Coverage Best Practices（新しいタブで開きます） Google Testing Blog

    https://testing.googleblog.com/2020/08/code-coverage-best-practices.html 2026-09-26 参照

  5. [5]

    Node.js Releases（新しいタブで開きます） Node.js

    https://nodejs.org/en/about/previous-releases 2026-09-26 参照

  6. [6]

    Next.js Support Policy（新しいタブで開きます） Vercel

    https://nextjs.org/support-policy 2026-09-26 参照

  7. [7]

    Release History (Release Policy)（新しいタブで開きます） The Go Project

    https://go.dev/doc/devel/release 2026-09-26 参照

  8. [8]

    Versioning Policy（新しいタブで開きます） PostgreSQL Global Development Group

    https://www.postgresql.org/support/versioning/ 2026-09-26 参照

  9. [9]

    The Twelve-Factor App（新しいタブで開きます） Adam Wiggins

    https://12factor.net/ 2026-09-26 参照

  10. [10]

    Check Documentation (Scorecard checks)（新しいタブで開きます） OpenSSF

    https://github.com/ossf/scorecard/blob/main/docs/checks.md 2026-09-26 参照

  11. [11]

    Capabilities: Code maintainability（新しいタブで開きます） DORA

    https://dora.dev/capabilities/code-maintainability/ 2026-09-26 参照

  12. [12]

    Capabilities: Loosely coupled teams（新しいタブで開きます） DORA

    https://dora.dev/capabilities/loosely-coupled-teams/ 2026-09-26 参照

  13. [13]

    5.5. Constraints (PostgreSQL 18 Documentation)（新しいタブで開きます） PostgreSQL Global Development Group

    https://www.postgresql.org/docs/current/ddl-constraints.html 2026-09-26 参照

  14. [14]

    Capabilities: Database change management（新しいタブで開きます） DORA

    https://dora.dev/capabilities/database-change-management/ 2026-09-26 参照

  15. [15]

    ウェブアクセシビリティ導入ガイドブック（新しいタブで開きます） デジタル庁

    https://www.digital.go.jp/resources/introduction-to-web-accessibility-guidebook 2026-09-26 参照

  16. [16]

    10 Usability Heuristics for User Interface Design（新しいタブで開きます） Nielsen Norman Group

    https://www.nngroup.com/articles/ten-usability-heuristics/ 2026-09-26 参照

  17. [17]

    What is the ASVS? (ASVS 5.0.0)（新しいタブで開きます） OWASP Foundation

    https://github.com/OWASP/ASVS/blob/master/5.0/en/0x03-What-is-the-ASVS.md 2026-09-26 参照

  18. [18]

    OWASP Top 10:2025（新しいタブで開きます） OWASP Foundation

    https://top10.owasp.org/2025/ 2026-09-26 参照

  19. [19]

    Well-Architected Framework: Security, privacy, and compliance pillar（新しいタブで開きます） Google Cloud

    https://docs.cloud.google.com/architecture/framework/security 2026-09-26 参照

  20. [20]

    Software Engineering at Google, Chapter 11: Testing Overview（新しいタブで開きます） Google

    https://abseil.io/resources/swe-book/html/ch11.html 2026-09-26 参照

  21. [21]

    Capabilities: Test automation（新しいタブで開きます） DORA

    https://dora.dev/capabilities/test-automation/ 2026-09-26 参照

  22. [22]

    Capabilities: Continuous integration（新しいタブで開きます） DORA

    https://dora.dev/capabilities/continuous-integration/ 2026-09-26 参照

  23. [23]

    Capabilities: Deployment automation（新しいタブで開きます） DORA

    https://dora.dev/capabilities/deployment-automation/ 2026-09-26 参照

  24. [24]

    Secure use reference (GitHub Actions)（新しいタブで開きます） GitHub

    https://docs.github.com/en/actions/reference/security/secure-use 2026-09-26 参照

  25. [25]

    Google Cloud Well-Architected Framework（新しいタブで開きます） Google Cloud

    https://docs.cloud.google.com/architecture/framework 2026-09-26 参照

  26. [26]

    Well-Architected Framework: Operational excellence pillar（新しいタブで開きます） Google Cloud

    https://docs.cloud.google.com/architecture/framework/operational-excellence 2026-09-26 参照

  27. [27]

    Site Reliability Engineering, Chapter 4 - Service Level Objectives（新しいタブで開きます） Google

    https://sre.google/sre-book/service-level-objectives/ 2026-09-26 参照

  28. [28]

    Site Reliability Engineering, Chapter 6 - Monitoring Distributed Systems（新しいタブで開きます） Google

    https://sre.google/sre-book/monitoring-distributed-systems/ 2026-09-26 参照

  29. [29]

    Capabilities: Monitoring and observability（新しいタブで開きます） DORA

    https://dora.dev/capabilities/monitoring-and-observability/ 2026-09-26 参照

  30. [30]

    Diátaxis（新しいタブで開きます） Daniele Procida

    https://diataxis.fr/ 2026-09-26 参照

  31. [31]

    C4 model（新しいタブで開きます） Simon Brown

    https://c4model.com/ 2026-09-26 参照

  32. [32]

    arc42 Template Overview（新しいタブで開きます） arc42

    https://arc42.org/overview 2026-09-26 参照

  33. [33]

    Architecture decision records overview（新しいタブで開きます） Google Cloud

    https://docs.cloud.google.com/architecture/architecture-decision-records 2026-09-26 参照

  34. [34]

    Capabilities: Documentation quality（新しいタブで開きます） DORA

    https://dora.dev/capabilities/documentation-quality/ 2026-09-26 参照

  35. [35]

    Capabilities: Working in small batches（新しいタブで開きます） DORA

    https://dora.dev/capabilities/working-in-small-batches/ 2026-09-26 参照

  36. [36]

    Capabilities: Trunk-based development（新しいタブで開きます） DORA

    https://dora.dev/capabilities/trunk-based-development/ 2026-09-26 参照

  37. [37]

    Capabilities: Version control（新しいタブで開きます） DORA

    https://dora.dev/capabilities/version-control/ 2026-09-26 参照

  38. [38]

    Capabilities: Streamlining change approval（新しいタブで開きます） DORA

    https://dora.dev/capabilities/streamlining-change-approval/ 2026-09-26 参照

  39. [39]

    DORA AI Capabilities Model report（新しいタブで開きます） DORA

    https://dora.dev/ai/capabilities-model/report/ 2026-09-26 参照

  40. [40]

    Capabilities: Clear and communicated AI stance（新しいタブで開きます） DORA

    https://dora.dev/capabilities/clear-and-communicated-ai-stance/ 2026-09-26 参照

  41. [41]

    Best practices for Claude Code（新しいタブで開きます） Anthropic

    https://code.claude.com/docs/en/best-practices 2026-09-26 参照

  42. [42]

    Security (Claude Code Docs)（新しいタブで開きます） Anthropic

    https://code.claude.com/docs/en/security 2026-09-26 参照