はじめに
TIG（Technology Innovation Group）の真野です。
フューチャーの有志メンバーで取り組んでいる「アーキテクチャ設計ガイドライン」のタスクフォース活動について、2025年の活動実績報告と振り返りの記事です。
アーキテクチャガイドラインとは
https://future-architect.github.io/arch-guidelines/
フューチャーでは、システム開発の現場で頻出する設計論点とその対応策を体系化したドキュメントをガイドラインとして整備し、GitHub Pagesおよび技術ブログで公開しています。
コンセプトは、単なる手順書や絶対的なルールブックではなくどうすべきかを考えるための議論の土台である点です。プロジェクト固有の事情を削ぎ落とし、汎用的な設計論点と推奨される解決策を提示することで、設計者が最適な判断を下すための補助線となることを意図しています。
これまでの歩み（2023年～2024年）
2025年に本格化したガイドライン作成の取り組みですが、活動自体は2022年頃から細々と始まっていました。簡単に経緯を紹介します。
2022年: 活動の萌芽（年1ペース）
もともとは、社内の別チーム（コアテクノロジーチーム）が公開していたJavaやSQLのコーディング規約に触発され、AWSインフラ命名規約 を作成したのが始まりです。各プロジェクトで何かしら命名ルールはすでにあるはずなので、持ち寄って最大公約数的な規約を作れば良いじゃないというどちらかというと緩い連帯的なスタンスでした。それゆえ拘束力は弱く作り上げるまでにかなり時間がかかった記憶です。
2023年: ゆるく継続（年1ペース）
OpenAPI Specification規約のv2版を公開しました。このころから現在に繋がるコアメンバーが自然と集まりました。しかし、未だ議論は散発的で統率が取れず、会議は開催したものの進捗は全員がないといったことも何回か発生したレベルでした。そのため、1つ仕上げるのに1年ほどかかりました。今振り返るとまだまだ牧歌的に活動していました。
2024年: 試行錯誤と転換点（年3ペース）
OpenAPI Specification規約のv3版、GitブランチフローやMarkdown設計ドキュメントなどを作成しました。1つのガイドライン作成に8～10ヶ月を要するなど、決してハイペースではありませんでした。転機となったのは2024年8～9月頃です。このくらいからWeb API・PostgreSQLの2ガイドラインを作り始め、全12回と期限を明確に区切って作成するポリシーとしました。エンドを決めることで個人的にパリッとした運営になり、個人的に運営方針の要だと感じるルールと認識しています。
2025年の活動実績
2025年は、アプリケーション、データ、インフラ、開発プロセスなど多岐にわたる領域で、合計 15本 のガイドラインを公開しました。それまでに比べると大分ペースアップできました。
公開ガイドライン一覧
- アプリケーション領域: Web API、Webフロントエンド、バッチ、I/F、メール、ログ、非同期
- データ領域: PostgreSQL、DynamoDB、データマネジメント
- インフラ領域: AWS、Terraform
- 開発プロセス: コードレビュー、Slack利用
- その他: ソフトスキル
活動データ
活動の規模を示す定量データは以下の通りです。
- 公開本数: 15本
- ドキュメント総量: PDF換算で合計1055ページ（1本あたり平均70ページ）
- 関与人数: 延べ 136名（作成者105名、レビュアー31名）。ユニーク59名（作成者43名、レビュアー25名、重複9名）。コアメンバー（3回以上参加）12名
- GitHub活動: Pull Request 数 242件、Issue 対応数 30件以上（Issueはほぼ公開コンテンツに対する改善対応）
業務の合間を縫う有志活動として、約1.5ヶ月に1本のペースで公開を継続しました。
作成プロセスと運営体制
短期間で一定量のドキュメントを作成・維持するために、以下の体制とプロセスを採用しています。
- AI活用:
- GeminiやChatGPT等の生成AIを、構成案の作成から誤字脱字チェック、レビューの補助として活用しています。AIが生成したテキストをそのまま採用するのではなく、人間の知見で取捨選択・リライトするプロセスを経て、品質を担保しています（感覚的には1割くらいは元の文が生きるかな？という印象です）
- 短期集中型のチーム組成
- 1つのガイドラインにつき2～3ヶ月という期限を設定し、4～8名程度のチームで集中的に執筆・レビューを行うスタイルをとっています
- 最初に何を議論すべきかブレストを行い、担当者までキックオフで決定。その後、2ヶ月枠であれば残りの7回の定例を週次で行い、各自アウトプットを全員でレビューする形式です
- 社内作業時は、社員的に最速で作業ができるGoogleドキュメントで管理しています
- GitHubによる版管理
- GoogleドキュメントやWordの校閲機能、textlint, markdownlint, GeminiのGemなどで確認してから公開します
- 公開後のドキュメントはGitHub上で管理し、公開後もPull Requestベースで継続的な修正・改善を行える運用としています
活用事例とフィードバック
公開されたガイドラインは、社内外のプロジェクトにおいて、設計のベースラインや議論の叩き台として利用されています。
実プロジェクトでの活用（匿名かつ抜粋）
具体的な活用シーンとして、以下のような事例が報告されています。
- 金融系などのプロジェクト
データマネジメントガイドラインで、AI-Readyなデータ基盤設計のヒントとして活用 - 製造系などのプロジェクト
Web API設計ガイドラインの内容がプロジェクトの標準規約として採用や、それに近い形で展開。APIゲートウェイ構築時の設計考慮点として活用 - インフラ系のプロジェクト
AWSのサービス選定で利活用
当初の想定通り、議論のベースラインとしての利用ができていることは確認できています。比較ができないため予測ですが、おそらく設計の手戻りなどを減らすことに微力ながら効果はあったと思います。
社外からの反応
SNS等において、エンジニアの方々より「実用的である」「設計の参考になる」といったフィードバックをいただいています。主観で一番多かったのは「長い」って反応だったと思います。これについてはもっと筋肉質にダイエットする打ち手を内部で考えています。
また、ガイドラインの公開がきっかけで技術的なお問い合わせにつながるケースもありました。
2025年の振り返り（KPT）
活動を通して得られた知見と課題を整理します。
- 成果（Keep）
- 年始に立てた目標数以上のアウトプットができ、主要な技術スタックを網羅できたこと
- 「ソフトスキル」など、形式知化が難しい領域についてもドキュメント化できたこと
- 課題（Problem）
- コンテンツ量の増加に伴い、過去記事のメンテナンス（棚卸し）工数が増加していること
- また、ガイドラインの提供だけでは、若手エンジニアの実践スキル向上に対して十分な効果を発揮しきれていない面があること。浸透については伸びしろあり
- 文量が長い
- 発信がXや技術ブログ程度。勉強会やカンファレンス登壇などでは発信できなかった
- 今後（Try）
- 実務における具体的な判断プロセスを補完するため、より実践的なシナリオ（例：「初めての〇〇」シリーズ）の拡充や、設計品質の底上げを図る「アーキテクチャ原則」の策定などを検討中
- 横断的に登場する「テスト」「ドキュメント」「セキュリティ」などの観点は、別紙に切り出して集約することで、個別パートからはリンクを貼るような関係で再構築する。それにより見かけの文量は減らす
- 各勉強会、カンファレンスで発信（お勧めや指名をお待ちしています）を実施し、認知度を高めつつフィードバックを貰う
おわりに
2026年も引き続き、データ領域（データガバナンス、BI、ETL等）の強化や、人材育成に資するコンテンツの拡充を進める計画です。
私たちのガイドラインは、フィードバックを受けて改善していくものです。
お気づきの点や、「自社ではこうしている」といった技術的な知見などがあれば、ぜひGitHubのIssueやXなどのSNS等でお寄せください。