はじめに

この記事は、株式会社asken (あすけん) Advent Calendar 2025の12/18の記事です。

こんにちは。バックエンドのテックリードをしている澤路です。

近年、AI を業務に活用することは当たり前になりつつあり、コード生成やレビュー補助、ドキュメント作成など、開発プロセスのさまざまな場面で恩恵を受けています。 asken も例外ではなく、日々の開発や調査業務において AI は欠かせない存在になっています。

一方で「意思決定」そのものは、いまだ人間が担っている領域です。前提条件・制約・将来の見通しといった複数の要素を考慮して決断するプロセスを、AIがどこまで再現できるかは未知数でした。

そこで、意思決定を「複数の立場からの議論を経た結果」として捉え直し、AI に異なる人格や役割を与えて議論させたうえで結論をまとめさせることで、人間に近い形で行えるのではないかと考えました。最近 Claude Code の sub-agent 機能を触る中でこの考え方を試せそうだと感じ、今回は過去に実際に行った技術選定を題材に、当時の前提条件だけを与えて AI に再度検討させ、その結果を見てみることにしました。

実施内容

今回は次の2点に注目して実施をしていきます。

人格や役割を与えずに検討させた場合と比べて、結果がどのように変化するのか
エージェントに与える人格や役割によって、考え方や議論に与える影響に違いが生まれるのか

題材として過去に実際に行われた技術選定の意思決定を用います。 2023 年に書かれたリアーキテクチャの意思決定に関する asken テックブログの「経緯」をインプットにします。

tech.asken.inc

あまり結果に影響を与えないように内容を抜粋して下記のようなプロンプトにしました。「あすけん」という文字が入っていると Claude が Web で検索して「既にKotlin+SpringBootに決まっています」と言われて結果に影響があったので削除しています。

システムをリアーキテクチャするための技術選定を行っています。

下記の点を議論して意思決定をしてください。

- どのような言語や技術スタックを選択すればよいですか？
- どのような開発手法や理論を使えば保守性を向上させることができますか？

## 背景

私たちの運用するサービスは2023年現在で10年以上の歴史があります。 嬉しいことに会員数も年々増加し、今年の7月には会員数が900万人を突破しました。 「ひとびとの明日を今日より健康に」というミッションを実現するために日々邁進しています。
しかし、長年に渡って機能の追加や修正が行われてきたソースコードは徐々に複雑さを増し、 開発速度への影響が無視できないレベルになっていました。
そこで私たちは、システムを再設計し複雑さを解消することで、開発速度の向上を目指すことにしました。
また、今までのバックエンドはPHPとCakePHPで作られてきました。 より保守性の高い設計をするために、技術セットにはこだわらず、PHP以外の言語も対象として検討することにしました。

## 注意点

- 出力ファイル名は `discussion-result-{yyyymmddhhmmss}.md` としてください
- 下記の内容を含めてください
    1. 結論
    2. 結論に対する簡単な説明(200 文字程度)
    3. 背景に記載がない前提
    4. どのようなことが検討されたかの詳細

sub-agent には下記のような人格を用意しました。 facilitator が全体をまとめ、必要な sub-agent を選択して議論します。

エージェント	人格説明
facilitator	意思決定のファシリテーター。複数の意見を整理・統合し、メリット・デメリットを比較して最終決定を導く。
advocate	ユーザー・顧客の視点を代弁する。技術議論に「実際に使う人はどう感じるか」という観点を持ち込む擁護者。
critic	批判的思考の達人。リスク、欠陥、見落としがちなデメリットを徹底的に洗い出す。悪魔の代弁者役。
ideator	ブレインストーミングの達人。多角的な視点から創造的なアイデアを次々と生み出し、選択肢を広げる。
optimist	物事の良い面やメリットに焦点を当てる楽観主義者。困難な状況でも成長の機会やポジティブな側面を見出す。
pragmatist	実行重視の現実主義者。抽象的なアイデアを具体的なアクションステップに落とし込み、リソースや制約を見極める。
researcher	調査専門家。 Web検索で最新情報、市場動向、競合分析、エビデンスを収集し、議論を事実で裏付ける。

結果まとめ

それぞれ 3 回実施しています。

sub-agent を使用しないパターン

結果	言語	フレームワーク	アーキテクチャ	移行戦略
結果 1	Kotlin	Spring Boot 3.x	DDD クリーンアーキテクチャ	ストラングラーフィグパターン
結果 2	Go	Echo または Chi	DDD クリーンアーキテクチャモジュラーモノリス	ストラングラーフィグパターン
結果 3	Go	記載なし	DDD クリーンアーキテクチャモジュラーモノリス	ストラングラーフィグパターン

静的型付け言語 + DDD によって保守性を上げるという方向性は当時の判断と一致しています。今回の結果で選ばれた Kotlin と Go も当時の検討と一致しています。
今回、検討された言語は PHP, Kotlin, Go, TypeScript, Rust になっています。採用言語の習得にコストをかけるのであれば Kotlin で、コストをかけないのであれば Go という判断になっています。
Go は学習コストの低さとパフォーマンスが強みとされ、フレームワークの成熟度が低いことなどが弱みに上がっていました
Kotlin は型の堅牢さと Java エコシステムを使用できることが強みとされ、PHP エンジニアの学習コストが高い点が弱みとしてあげられていました

sub-agent を使用するパターン

結果	言語	フレームワーク	アーキテクチャ	移行手法
結果 1	PHP 8.x	Laravel	戦術的DDD クリーンアーキテクチャモジュラーモノリス	ストラングラーフィグパターン
結果 2	PHP TypeScript	Laravel 11 Vue.js 3	戦術的DDD モジュラーモノリス	ストラングラーフィグパターン
結果 3	PHP 8.x	Laravel	DDD クリーンアーキテクチャモジュラーモノリス	ストラングラーフィグパターン

それぞれの結果で使用された sub-agent は下記です

結果	researcher	critic	pragmatist	advocate	ideator	optimist	facilitator
結果 1	○	○	○	○	○	✕	○
結果 2	○	○	○	○	✕	○	○
結果 3	○	○	○	○	○	✕	○

3つの議論すべてで、PHPから他言語への移行は高リスク・高コストであり、設計・アーキテクチャの改善が本質的な解決策であると結論付けられています。
critic と pragmatist はリスクの低さや実現可能性の観点から PHP を支持しており、その結果が強く反映されたように感じました。
critic と pragmatist は下記のような類似した主張をしています。
- 真因分析を優先して課題の原因特定をすべき
- 言語が原因ではなく、設計に注力すべき