本記事では、三井住友カードのデジタルプロダクト開発を手の内化するための環境である「Polaris」の設計・構築・運用について全8回（予定）で連載します。
「プラットフォームエンジニアリング」 「AIと一緒にプラットフォーム構築」
をどのように実践しているかを現場目線からご紹介させていただきます。
目次
この記事のまとめ（TL;DR）
- 三井住友カードでは、最新のAIやクラウド等を活用したIT・デジタルプロダクト開発を専門的に行う本部として2026年4月にデジタルイノベーションオフィスを新設
- プラットフォームエンジニアリンググループでは、社内開発プラットフォームおよび本番稼働環境である「Polaris」を「手の内化プラットフォーム」としてゼロから構築
- 「Polaris」で体現していくプラットフォームエンジニアリング と AI活用したプラットフォーム構築について、苦労話も含めて連載形式でお届け
- 初回の学びは、「検討期間を長くするよりも、ある程度の検討をして、本当に実装できるのかどうかを"AIと一緒に""手戻り覚悟で"どんどん試していくことが、プラットフォームエンジニアリングにも繋がる」
ゼロからのプラットフォーム構築をAIと一緒に
こんにちは。
デジタルイノベーションオフィス
プラットフォームエンジニアリング グループの児島です。
私たちは手の内化プラットフォーム「Polaris」を構築・運用しています。
キャッシュレス決済を支えるサービス群が、より速く・安全に・自分たちの手でリリースできる(=お客様に迅速に価値を届けられる)状態を目指して、手の内化プラットフォームをゼロから組み上げています。
最大の特徴は、最初から「AIと一緒に作って、育てて、運用していく」ことを前提に設計・運用していることです。
この連載では、私たちが構築している手の内化プラットフォーム 「Polaris」 の構築・運用の裏側を発信していきます。
初回では、そもそも「なぜ、手の内化を選択したのか」「Polarisとは何か」「なぜ、AIと一緒に作るのか」という内容を書きます。
なぜ「手の内化」を選択したのか
- The most innovative cashless company 〜未来の当たり前をつくる、最も先進的なキャッシュレスカンパニー〜
当社は、昨今のAIによるゲームチェンジ、そしてキャッシュレス決済領域の変化の速さのなか、ビジョンを掲げています。
これを実現するには、技術を含めた主権を自分たちで持ち、コントロールすること＝「手の内化」の推進が必要だと考え、最新のAIやクラウド等を活用したIT・デジタルプロダクト開発を専門的に行う本部として2026年4月にデジタルイノベーションオフィスが新設されました。
なお、「手の内化」とは、当社がIT・デジタル領域で経営の柱に据えている方針で、単なる内製化ではなく、「自分たちのアタマとテクノロジーで、事業もシステムも動かせる状態」を指します。
「手の内化」により、以下を実現していくことが私たちのミッションとなります。
- キャッシュレス決済という変化の速い領域で、お客様により早くサービスおよび価値を提供する
- 仮説検証を素早く繰り返しプロダクトを磨いていく
「Polaris」の構築
Polaris（ポラリス）とは、私たちが構築・運用している「手の内化プラットフォーム」の総称です。
「Polaris」とは北極星のことであり、古来より道しるべや拠り所として扱われてきました。
そのようにソフトウェアエンジニアを導くような環境/プラットフォームにしたいという意味を込めて、命名をしました。
なお、Polarisの構築期間は、以下になっています。
- 2025年12月〜2026年4月：内部開発者環境（IDP）の構築
- 2026年4月〜2026年6月：ランディングゾーン/マルチアカウント環境の構築
Polarisは大きく分けて、以下のカテゴリで構成しています。
| レイヤー | 役割 | 主な技術（例） |
|---|---|---|
| ゴールデン・パス | ソフトウェアエンジニアが開発をスピーディかつ安全に行うための環境 | IDP（RHADS等） / SCM / AI駆動開発ツール（Claude Code等） / CI/CDパイプライン |
| ガバナンス・ランディングゾーン | 稼働環境を安全に統合管理する機能 | AWS Organizations / Control Tower |
| ネットワーク | 通信の集約・制御する機能 | AWS Firewall Manager / Transit Gateway |
| コンテナ基盤 | アプリ実行環境 | Red Hat OpenShift Service on AWS（ROSA） |
| セキュリティ | 脅威検知を担う機能 | Cloud Security Tool（Wiz） / AWS Security Hub |
| 可観測性 | アプリおよび基盤情報を可視化・監視・観測する機能 | Observability Tool（Dynatrace） |
なぜ、最初から「AIと作る」選択をしたのか
Polarisの最大の特徴は、「AIファースト（AIネイティブ）」を掲げ、構築のはじめからAIをプラットフォームづくりの軸に据えたことです。
これは構築（AI駆動開発/AIDD：AI-Driven Development）だけでなく、運用（AIを活用したシステム運用/AIOps：AI for IT Operations）も同様です。
私たちは、インフラの設計および調査・コード作成・レビュー・検証、といった作業の多くを、AIエージェント（主に Claude Code）と協働で進めています。また、運用でもAIOpsを見据えた製品選定を進めました。
AIを単なる補助ツールとしてではなく、「AIと一緒に基盤を作る・運用する」ことを前提に、チームの進め方そのものを設計しました。
なぜそこまでするのか。理由はシンプルで、少人数で、手の内化プラットフォームを、速く・安全に作り切り、安定的に運用するためです。
ただし、AIに任せればすべてうまくいく、という話ではありません。
実際、私たちも「提案・回答が誤っている」「外部要因（AWSのQuotas等）の制約を確認しない」「外部サービスの仕様把握が甘い」といったAIと一緒に構築するからこその失敗も経験しました。
ただ、チームモットーである「（本番は除いて）手戻り覚悟でまずはやってみよう！」「構築の中ではチャレンジングにTry&Errorしていこう！」を念頭に推進していたため、AIと一緒に調査・検討していく、スピードを活かした運営で乗り切りました。
そこから、AIに安全に仕事を任せるための"ガードレール" をチームで育てています。
こちらの試行錯誤は、今後の連載の中で詳細や苦労をお話しできればと思います。
立ち上げで最初にぶつかった壁 ―― 「何から手をつけるか」
最後に、第1回の「課題と学び」を一つ。
ゼロから基盤を作るとき、最初に悩んだのは「何から手をつけるか」でした。少数エンジニアで立ち上げる環境、かつ、自社開発環境が全くない状況だったため、「最初の一歩」を決める・動き出すことが一番難しかったです。
プラットフォーム構築をするにも、「どういったものを」「誰が」、「どこに」、「どういった基準/統制で」、「何から」構築していくのか、ほぼ全てがゼロからのスタートとなる状況でした。
ただ、明確だったのは当社ビジョンを達成するために「手の内化プラットフォーム」を短期間で作り上げるということでした。
そして、結論としては、全てを並行で動かして走りながら具体化をしていく - 「AI活用による作業スピード向上を活かした」運営を軸に、プラットフォーム構築を進めるということでした。
| 項目 | 課題感 | 当時の判断 |
|---|---|---|
| 誰が | 自社内にエンジニアがほぼいない | AIと一緒に構築しながら、エンジニア採用も並行で進める |
| どこに | 開発・本番環境がない | 手の内化前提で、自社環境として新規構築 |
| どのように | 具体的な要件はなし | マルチアカウント構成と外せない要件/統制だけ先に確定。他詳細は構築と一緒に検討しながら |
| いつまでに | この環境がなければ開発・プロダクト発信ができない | 短期間かつ最低限必要機能を提供。改善活動を継続して行う |
| 何から | 全てがゼロからで、どこから手をつけるか | まずはIDPを構築、ソフトウェアエンジニアが必要とする箇所から |
とても大事だったと感じているのは、
最終的な環境として何を目指すのかを明確にする一方で、
検討期間を長くするよりも、ある程度の検討をして、本当に実装できるのかどうかを"AIと一緒に""手戻り覚悟で"どんどん試していったという点です。
最初に検討した構成では意外と使いづらかったり・やりたいことができないといった点が実装の中で出て来ることもあり、"手戻り覚悟で試す"ということは、運用含めたGAPを早期に洗い出すことができたと感じています。
なお、Claude CodeのSkillsにcontextを設定し、Planを活用して進めることで手戻りの時間短縮を行いました。
それにより、私たちが目指すプラットフォームエンジニアリングを体現するためにも、プロダクト開発チームが触れる環境を早く用意して、開発チームに伴走して環境整備していくことができたことも結果的に良かったと感じています。
具体的な構成見直しが発生した「ネットワーク構成」等の見直しについては、連載の中でどういった内容か・どのように乗り越えたかについて、お話しできればと思います。
学び：ゼロからの構築ではあるものの、検討期間を長くするよりも、軸の検討およびそれだけブラさずに、実装面では"AIと一緒に""手戻り覚悟で"どんどん試していくことが、環境構築の短期化に繋がる可能性もある。
この連載で語ること（全体の見取り図）
初回は概要になりましたが、
連載では、Polarisが立ち上がっていく時系列に沿って、各担当メンバーの具体的な内容や苦労話を交えて投稿していこうと思います。
なお、連載としては8回程度を予定しています。
また、Polarisは今も改善活動を含めてレベルアップをしている状況です。
色々なフェーズで出てきた課題とそれを乗り越えた内容などを発信していければと思っていますので、ぜひご愛読いただけますと幸いです。
次回予告
第2回（予定）は、「ゼロからのスタート ― IDPの構築」。
前述の通り、プラットフォーム構築を並行で進めたものの、まずは「開発環境」を整備することが最優先でした。その中でも、AI駆動開発や開発者ポータルを導入した経緯について、紹介しようと思います。
一緒にPolarisを育てませんか
プラットフォームエンジニアリンググループでは、クラウド基盤・プラットフォームエンジニアリング・SREに挑む仲間を募集しています。モダンな技術スタックと、AIと協働する開発文化の中で、金融基盤をゼロから手の内化する経験ができます。
エントリーをしたい方はこちらから
