ITアーキテクトとは何者か ― 生成AI時代のアーキテクチャ超入門

本記事について

当サイトを閲覧いただきありがとうございます。 本記事はシリーズ『生成AI時代のアーキテクチャ超入門』の本編1本目として、「ITアーキテクトとは何者か」というテーマで、アーキテクトという役割の全体像と判断軸を整理する記事です。

本シリーズ全体の位置づけは前回の『シリーズの歩き方』に整理してあります。

本記事のテーマについてさらに詳しく知りたい方は『情報処理教科書 システムアーキテクト 2025～2026年版』・『アーキテクトの教科書』も参考にしてみてください。

そもそもITアーキテクトとは何か

「アーキテクチャ」とは

アーキテクチャ（Architecture）は元々、英語で「建築学・建築術・構造」を意味する言葉です。語源はギリシャ語の arkhitekton（大工の棟梁）で、設計の全体を統括する人・その設計思想そのものを指します。

IT分野ではシステム開発を建築に例えることが多く、システムの構造・設計全般・設計思想を全て含めて「アーキテクチャ」と呼ぶようになりました。

建築と同じく、一度建てた骨組みはあとから変えるのが極めて難しく、最初の設計がその後数年〜数十年の運用を左右します。「家を建てる」メタファーが繰り返されるのは、後戻りの重さが似ているからです。

ITアーキテクトの仕事

ITアーキテクトとは、ざっくり言えば「システムの骨格を決める人」です。

ただし設計といっても、画面モックを描く人やクラス図を書く人のことではありません。どの言語で、どのクラウドで、どんな構造で、どうデプロイするのかを決める人です。

一般的なプロジェクトではテックリード（Tech Lead、技術面をリードする役割）あるいはリードエンジニアとして活動することが多く、チーム内の技術決定の最終責任を持ちます。

近年のDX推進において、アーキテクトの役割は年々重要になっています。ビジネスの形がソフトウェアそのものに乗る時代では、システムの骨格がそのまま事業の骨格になるからです。

アーキテクトは「コードを書く人」と「絵を描く人」の境界にいます。コードを1行も書かないアーキテクトは現場との接点を失って机上の空論に陥り、コードしか書かないアーキテクトは組織的な意思決定から外れて影響範囲が狭くなります。両方に軸足を置き、技術判断と組織判断を同時に回せるのが一人前のアーキテクトです。

アーキテクトは役職ではなく「役割」だと、私は考えています。今の肩書きに関係なく、明日からでも設計判断に名前を残せる立場です。

業界で起きていること

2020年、Segment という分析基盤の会社が「Goodbye Microservices」というブログ記事を公開し、140以上に膨れ上がったマイクロサービスをモノリスに戻したと宣言しました。

2013年の当時、マイクロサービス化は業界の教科書的な正解でした。しかし5年後には同じ選択が負債扱いされている。つまり「主流だから正しい」は、5年経つと「主流だったから負債」に反転することもあるのです。

こうした反転が繰り返される領域で、システムの骨格を決めて、その理由を残す。それがITアーキテクトの仕事です。AIがコードを書く時代になっても、いやAIがコードを書く時代だからこそ、この役割の価値はむしろ上がっています。

AIは「どう書くか」の答えは持っていますが、「何を作るか」「なぜこれを選ぶか」の答えは組織の文脈に依存するため、出せません。

なぜアーキテクトが必要なのか

「動けばいい」では済まない

個人開発でバイブコーディング（自然言語でAIに要件を伝え、生成されたコードを人がレビューしながら進める開発スタイル）を経験すると、「動くものが作れるならアーキテクチャなんて要らないのでは」と思うかもしれません。

個人開発ならその考えでも何とかなることは多いのは事実です。しかし、それなりの規模のシステムでは「機能要件（システムで何ができるか）」だけではなく、「非機能要件」が極めて重要となります。

「機能要件」だけを実現すれば良いなら、クラウドでもオンプレでも何でも構いません。ログイン機能があり、データが保存でき、画面が出れば要件は満たされます。

ですが、現実のシステムにはコスト・性能・セキュリティ・可用性・拡張性・保守性といった「非機能要件」があります。これらを満たすために、どの技術を・どう組み合わせるかを決めるのがアーキテクチャの仕事です。

機能要件は「何ができるか」を問い、非機能要件は「どれくらいちゃんとできるか」を問います。機能要件だけを見ていると、どんな選定も「動けばOK」になってしまい、本番投入後に性能が出ない・障害が頻発する・運用コストが暴騰する、といった形で問題が噴出します。

アーキテクチャ設計とは、非機能要件を満たすための意思決定の束と言い換えることもできます。

やり直しが困難だから

システムは一度作ってしまうと、後から根幹部分を変更することはほぼ不可能です。言語を変えるのも、DBを変えるのも、クラウドベンダーを変えるのも、実質的に「作り直し」と同義の工数が発生します。

だからこそ構築を始める前の段階から、知識とスキルを持ったITアーキテクトがアーキテクチャを作る必要があります。

後戻りの重さは建築と同じです。壁紙の張り替えなら気軽にできますが、柱の位置を変えるのは家を建て直すに等しい。アーキテクチャ判断のうち、どれが壁紙で、どれが柱なのかを識別することが、アーキテクトの第一の仕事と言えます。

いつ決めるか

アーキテクチャ判断のタイミングは、対象によって変わります。全てを最初に決める必要はありませんが、後から変えられないものほど早く決めるのが原則です。

上の表で「企画・計画段階」に並んでいる項目は、後から変更すると実質的に作り直しになるものです。一方、下にいくほど走りながら調整する余地が残ります。

先送りすると、下流の判断が仮決めのまま進み、上流が確定した時点で大規模な手戻りが発生します。特にクラウドベンダー・主要言語・DB選定といった根幹の判断を後回しにすると、チーム全体の作業が手戻りの波に飲まれます。

アーキテクチャにはどういったものがあるか

代表的な種類

アーキテクチャは対象範囲によって複数の種類に分かれます。本シリーズでもこの分類に沿って記事を整理しています。

この分類は固定ではなく、会社ごと・プロジェクトごとに粒度が変わります。重要なのは「どのレイヤーで設計判断が必要か」を理解し、それに対応できるアーキテクトを配置することです。大規模プロジェクトではレイヤーごとにアーキテクトが分かれ、小規模なら1人が全てを兼務します。

用語の補足として、モノリス（1つの大きなアプリにまとめる構造）とマイクロサービス（小さなサービスを複数つなげる構造）は、本シリーズで頻出する概念です。詳細は「ソフトウェアアーキテクチャ」カテゴリで扱います。

アーキテクトの判断軸

ここからは、アーキテクトが判断を行う際に軸となる考え方を紹介します。

正解は無いことを受け入れる

アーキテクチャ設計において最も重要な心得は、「正解は無い」ことを受け入れることです。

企業固有の事業背景・技術制約・開発者スキル・既存システム構成の総合判断が必要で、普遍的な正解は存在しません。

2013年頃のマイクロサービスは「新時代の正解」として業界を席巻しました。それが2020年には「運用負荷が高すぎる」と揶揄され、モノリス回帰の事例が増えています。巨大テック企業ですら5年単位で設計思想を入れ替えています。

ここで意識しておきたいのがCAP定理です。分散システム（クラウド含む）では、「データの完全な整合性」「常に止まらない可用性」「ネットワーク分断耐性」の3つを同時に満たすことは原則不可能、というのがこの定理の内容です。

SNSならデータが数秒古くても画面を表示する、銀行の残高表示ならエラーにしてでも間違った数字は見せない。どちらを取るかで下流の技術選定が全て決まります。正解は業務要件次第で変わるという、アーキテクチャ判断の本質を体現した概念です。

また、IT業界には元々あった技術や概念を新しい言葉に言い換えて完全な新技術のように見せかける製品やサービスが非常に多くあります。「ASP」「WEBサービス」「クラウドサービス」「SaaS」は技術的にはほぼ同じものです。流行の言葉に振り回されず、技術や概念の本質が何かを常に考える姿勢がアーキテクトには求められます。

One-way Door は慎重に、Two-way Door は速く

Amazonのジェフ・ベゾス氏が提唱した意思決定モデルです。意思決定を「後戻りできるもの」と「後戻りできないもの」に分類し、後者だけに時間を使う考え方で、アーキテクト実務における最も有用なフレームワークの一つです。

One-way Door と Two-way Door を同じ重さで扱うと時間配分が狂います。Two-way Door に時間をかけすぎて One-way Door を軽く決めてしまう、という逆転は典型的な失敗パターンです。

戻れる判断は速く、戻れない判断は慎重に。この原則を外すとプロジェクトは遅延と負債の両方を抱え込みます。

シンプルさを保つ

小規模システムへのマイクロサービス採用、将来を見越して使うかも分からない機能の事前準備、全レイヤーをインターフェースで抽象化する設計。これらは一見高度に見えても、多くの場合で時間とコストの浪費になります。

YAGNIという原則が、過剰設計への最も強い抑止力です。

「よりシンプルな実現方法は無いか？」を常に問い続ける習慣が、過剰設計を避ける唯一の方法です。思慮深い人や経験を積んだ人ほど将来のことを考えて層を重ねたくなりますが、その層のほとんどは使われないまま運用コストだけを食い続けます。

過剰設計はある意味経験者の病とも言えます。退屈な設計を選ぶ勇気が長期を決めます。

チームで運用できるか

どんなに高尚なアーキテクチャでも、チームメンバーが理解できない・実装できないものは失敗します。アーキテクトが一人で惚れ込んだ理想設計が、現場で1週間後に崩壊する光景はよく見ます。

「チームメンバーのスキルで運用できるか？」を常に問う姿勢が大事だと、私は考えています。理解されない設計は存在しないのと同じです。

AI駆動開発を前提にする

バイブコーディングの浸透により、AIが業務コードを大量に書く時代が本格化しました。アーキテクトの判断軸も「AIに書かせやすく・読ませやすい設計」を前提としたものへ変わります。

用語の補足です。IaC、OAuth / OIDC（ログイン連携の業界標準プロトコル）、ACID（DBが守る整合性の古典的保証：原子性・一貫性・独立性・永続性）、分散TX（複数DBを跨ぐトランザクション）。

「AIに優しい設計」と「人間にも優しい設計」は、長期保守の軸では重なる部分が大きいと私は考えています。主流プロトコルや主流製品はAIの学習データが豊富でハルシネーション（誤った内容を自信ありげに出力する現象）が少なく、人間にとってもドキュメントが豊富で引き継ぎが楽です。

独自実装・内製フレームワーク・GUIのみツールは、AI時代に最も確実に負債化する選択です。

やってはいけないこと

アーキテクトが事故を起こす典型パターンを5つに絞って整理します。

1. 「○○が主流だから」で決定する

組織の制約・既存資産・人材を無視して主流技術に飛びつくパターンです。Segment のマイクロサービス回帰（2020年）、Amazon Prime Video のモノリス統合でインフラコスト90%削減（2023年）が象徴的で、巨大テック企業ですら5年で設計思想を入れ替えています。選定理由は「主流だから」ではなく、自分たちの制約から導くものです。

2. ADRを残さず決定する

意思決定が属人化し、後任が「なぜこれにした？」に答えられなくなります。2年経てば提唱者が辞めているか記憶が曖昧になっており、結論だけが残ったシステムは「触るな」で硬直化します。詳細は次のセクションで解説します。

3. 将来の備えで層を重ねる（過剰設計）

将来の可能性に備えて抽象レイヤーを重ね、結局その層は使われないまま運用コストだけが残る典型です。YAGNI（いま必要ないものは作らない）で判断してください。

4. チームスキルを無視した理想設計

美しい設計でもチームが運用できなければ失敗します。認知負荷の上限を超えた設計は必ず形骸化します。

5. One-way Door を軽く扱う

後戻り不能な決定（言語・DB・クラウドベンダー）を、Two-way Door と同じスピードで決めてしまうパターンです。本当に慎重さが必要な決定を軽く済ませてしまうと、数年単位の負債を抱えることになります。

決定理由の残し方（ADR）

アーキテクチャを決定した理由を見える形で残しておくことが、ITアーキテクトとして最も重要な行動です。結論だけが残っていても、数年後に「なぜこの選択か」を誰も説明できないシステムは、必ず負債化します。

残す理由は次の通りです。

• 後から入った人が設計思想を理解できる
• 開発途中・運用開始後に当初の目的を実現できているか判断できる
• 次の開発に活かせる重要な情報になる

最も普及している形式がADRです。1決定＝1ファイルで、Gitに乗せて版管理できます。

# ADR-0001: データベースに PostgreSQL を採用する

## 状態:  承認済み（2026-04-01）

## 背景
トランザクション整合性と全文検索を両立する必要がある。

## 決定
PostgreSQL を採用（MySQL・DynamoDBを棄却）。

## 根拠
- JSON型・全文検索・地理情報を標準サポート
- ACID準拠で金額計算に安全
- AWS RDS / Auroraでマネージド運用可能

ADR を書く文化が根付いているチームは、新メンバーのオンボーディングが速く、技術判断の質が安定します。逆にADRがないチームは、同じ議論を毎年繰り返し、過去の失敗を繰り返します。

なお、アーキテクチャの決定事項は固定ではなく、修正が必要になった場合はITアーキテクトに確認を取った上で変更し、ADRにも反映して最新化します。文書が実態と乖離した瞬間、文書は「過去の地図」になり、誰からも信用されなくなります。

ADRが無い現場で起きること

ADRが無い現場で何が起きるか、業界でよく聞く事例を紹介します。

とあるBtoB系SaaSで、バックエンドのメッセージキューに珍しめのミドルウェアが採用されていました。普通なら RabbitMQ か Kafka を選ぶところで、あえて別のプロダクト。当時の設計者は「何らかの理由があったに違いない」と皆が思っていました。

しかし3年後にその設計者は退職済み。ADRもなく、Slackの古いスレッドを掘り返しても判断の記録は出てきませんでした。

運用チームは「何か意味があるはずだから触るな」と3年間放置し、そのミドルウェアのバージョンアップに追従できず、セキュリティアラートが積み上がり、最終的に本番で半日止まる障害を起こしたとのことでした。

ポストモーテム（インシデント後の振り返り）で原因を追うと、当初の選定理由は「そのとき設計者が趣味で触りたかった」という推測に落ち着いたそうです。真相は今も不明とのこと。

1決定1ファイルのADRを5行でも残しておけば、後任は「この前提が崩れたから別の選択肢を検討する」と自信を持って動けたはずです。残っていないと、誰もが「触るな」で保身に走ります。アーキテクチャで時を超えて残るのは、結論ではなく理由です。

この記事に関連する記事

まとめ

本記事は「ITアーキテクトとは何者か」というテーマで、AI時代に価値が上がるとされるこの役割について解説しました。如何だったでしょうか。

アーキテクトは「役職」ではなく「役割」であり、システムの骨格を決めて、その理由を残す人です。AIがコードを書く時代だからこそ、「何を作るか」「なぜこれを選ぶか」を決められる人間の価値が上がっていきます。

プロジェクト立ち上げ時にアーキテクトが決めるべき代表的な項目を、最後に整理しておきます。

• アプリケーション形態（Native / Web / Hybrid）
• デプロイモデル（クラウド / オンプレ / ハイブリッド）
• 主要言語・主要フレームワーク
• データストアの選定（RDB / NoSQL / 併用）
• 認証方式（自前 / IDaaS）
• 非機能要件の目標値（可用性・性能・セキュリティ）
• ADRの運用ルール（どこに・誰が・いつ書くか）

「正解は無い、ゆえに理由を残す」が核心です。それが次のアーキテクトへの最大の贈り物だと、私は考えています。

次回の記事では「学習ロードマップ」というテーマで、自分の立場・経験別にどの記事から読めばいいかを具体的に整理していきます。

シリーズ目次に戻る → 『生成AI時代のアーキテクチャ超入門』の歩き方

本記事で扱った内容の詳細は AWS トレーニングと認定 も合わせて参考にしてください。

それでは次の記事も閲覧いただけると幸いです。