親子エージェントのモデル組み合わせ7通りを、テストで比較してみた

はじめに

AIエージェントに開発を任せる方法として、「親エージェント(PM兼テックリード)」が仕様書を書いてレビューし、「子エージェント(実装担当)」がコードを書く分担がよく使われます。ここで迷うのが親と子にどのモデルを割り当てるかです。全部を上位モデルにすると費用がかさみ、子を軽量モデルにすると差し戻しが増えるかもしれません。

今回 GTP-6、Opus5.5が使えるようになったので、改めて比較検証してみます。

AI に実装を任せるなら、まずこの種の処理で任せられるかどうかを確かめたいと考えました。そこで、クーポン・送料・消費税・ポイントを扱う請求書計算モジュールを題材にして、Claude(Opus 5.5 / Sonnet 5.5)と Codex(GPT-6 Sol / GPT-6 Luna)を組み合わせた7つの構成を比べました。見た項目は金額・実装時間・巻き戻し回数・隠し受入テストでの不具合率の4つです。

結論

GPT-6 親子ともGPT-6の構成だけが、不具合を防げなかった。
子として書くテストの件数は、Claude が GPT-6 の数倍だった（今回のケースでは品質の差にはつながらなかった）。
親が Opus なら、コードを書く子は Codex の方が費用対効果が高い。

今回の課題では、親 Opus 5.5 / 子 GPT-6 Sol(構成C) が、3回とも巻き戻し0回・不具合0%でした。実装時間は平均で最短でした。金額は API 料金で換算して1.15ドルで、不具合0%の構成の中では最安の D(1.06ドル)とほぼ同額です。

WEBアプリを作成する事に関しては、十分に性能が足りているので、FableやAstraは使わなくてよいかと思います。
それより、トークン効率上げて、並列処理を行った方がいいです。
Lunaが驚くほど安いので、どう上手く組み込むかがテクニックになります。

検証環境

項目	内容
OS	Windows 11
ランタイム	Node.js 24
Claude Code CLI	2.1.284(Claude デスクトップアプリ同梱版)
Codex CLI	0.158.0-alpha.2.1
モデル	claude-opus-5-5 / claude-sonnet-5-5 / gpt-6-sol / gpt-6-luna
推論の強さ	Codex = medium、Claude = CLI の既定値
実行モード	ヘッドレス(claude -p --output-format json / codex exec --json)、承認なしモード
実行日	2026-09-29

承認なしモード(Claude は bypassPermissions、Codex は --dangerously-bypass-approvals-and-sandbox)を使ったのは、無人で回すためです。実行は検証専用の作業フォルダの中だけに限りました。

この記事の時点では、検証用リポジトリと隠し受入テストは公開していません。記事中のコードは、リポジトリから短く抜き出したものです。

やってみた

比較した7構成

ID	親	子	ねらい
A	Opus 5.5	Opus 5.5	Claude だけのベースライン
B	GPT-6 Sol	GPT-6 Sol	Codex だけのベースライン
C	Opus 5.5	GPT-6 Sol	親 Claude + 子 Codex(上位)
D	Opus 5.5	GPT-6 Luna	親 Claude + 子 Codex(軽量)
E	GPT-6 Sol	Opus 5.5	親 Codex + 子 Claude(上位)
F	GPT-6 Sol	Sonnet 5.5	親 Codex + 子 Claude(中位)
G	GPT-6 Sol	GPT-6 Luna	親 Codex + 子 Codex(軽量)

課題:請求書計算モジュール(上級版)

外部ライブラリを使わない Node.js のモジュールと CLI を作る課題です。要件書に書いた主な内容は次のとおりです。

• 複数クーポン(最大3枚)。rate → amount の適用順、カテゴリ限定、最低購入額、クーポン対象外の商品
• 割引額を明細ごとに按分し、端数は「残額の大きい明細から1円ずつ」配る
• 地域別の送料(5,000円以上で無料。ただし離島は常に有料)
• 消費税の端数処理3方式(floor / round / ceil)を、税率グループごとに1回だけ適用
• ポイントの利用上限(税込合計の半額まで)と付与ポイント
• 17種類のエラーコードと、チェックする順序
• CLI(- を指定すると標準入力から読む、--rounding オプション、終了コードの使い分け)

最初は、これより簡単な基本版(受入テスト48件)を用意しました。しかし構成Cを1回試した時点で、巻き戻し0回・不具合0%・6.2分となりました。構成の間で差が出にくいと判断し、上級版を作りました。

仕組み

公平に比べるため、次の3点をそろえました。

• 親から子への委任は必ず child.mjs を通す。Claude 内蔵のサブエージェント(Agent / Task ツール)は使えないようにしました。こうすると、親が Claude でも Codex でも同じ経路で子が呼ばれ、呼び出しごとのトークン数と時間が記録されます。
• 子は毎回まっさらな状態で起動する。子は会話履歴を持たないので、必要な情報はすべて親が指示ファイルに書く必要があります。
• 差し戻し(fix)は最大3回まで。

親への指示テンプレートでは、委任に使うコマンドを次の1つに絞っています。

node "{{CHILD_CMD}}" --phase <phase> --prompt-file <指示ファイルのパス>

phase は impl / test / fix / other の4種類です。親には「レビューまたはテストで不具合が見つかって差し戻すときは、必ず fix を使う」と指示しています。この fix を呼んだ回数を、そのまま巻き戻し回数として数えます。

child.mjs(委任の唯一の入口)

子の CLI を起動し、呼び出し1回ごとに JSONL を1行書き足します。

// bench/child.mjs(抜粋)
const res = await runWithRetry(cfg, agent, prompt, {
  cwd: process.cwd(),
  env: { BENCH_METRICS_DIR: '', BENCH_CHILD_AGENT: '' }, // 子からの再委任は不可
  timeoutMs: cfg.childTimeoutMin * 60_000,
  rawLog: join(metricsDir, 'child_raw.log'),
});
appendFileSync(join(metricsDir, 'child_calls.jsonl'), JSON.stringify({
  phase, promptFile, agent: agentKey, model: agent.model, startedAt: started.toISOString(),
  activeMs: res.activeMs, waitMs: res.waitMs, attempts: res.attempts, ok: res.ok, exitCode: res.exitCode,
  timedOut: res.timedOut, rateLimited: res.rateLimited, usage: res.usage, tokens: totalTokens(res.usage), costUsd: res.costUsd,
}) + '\n');

環境変数を空にして子を起動しているので、子がさらに孫へ委任することはできません。

計測の要点

金額:記録したトークン数を、API 料金で換算した額です。料金は2026-09-30に各社の公式ページで確認しました。ただし GPT-6 Sol だけは、確認した時点の料金ページに載っていなかったため、筆者が把握していた単価を使っています(下の表の注記を参照)。Claude は、CLI が出力する total_cost_usd を使います。Codex は、turn.completed イベントの usage に単価を掛けて計算します。

// bench/lib.mjs parseCodex(抜粋)
if (ev.type === 'turn.completed' && ev.usage) {
  // ...
  // Codex の input_tokens はキャッシュ分を含む総入力
  usage.input += (ev.usage.input_tokens ?? 0) - (ev.usage.cached_input_tokens ?? 0);
  usage.cacheRead += ev.usage.cached_input_tokens ?? 0;
  // ...
  usage.output += ev.usage.output_tokens ?? 0;
  // ...
}
// ...
const costUsd = (usage.input * p.input + usage.cacheRead * p.cachedInput + usage.output * p.output) / 1e6;

使った単価(USD / 100万トークン)は次のとおりです。

モデル	入力	キャッシュ読み込み	キャッシュ書き込み	出力
Claude Opus 5.5	4.00	0.20	8.00(1時間キャッシュ)	20.00
Claude Sonnet 5.5	2.00	0.20	4.00(1時間キャッシュ)	10.00
GPT-6 Sol	2.00	0.20	-	10.00
GPT-6 Luna	0.10	0.01	-	0.50

• Claude は claude.com の料金ページの値です。Claude CLI は1時間キャッシュを使っていて、その書き込み単価は入力の2倍です。有効な21試行に含まれる Claude の呼び出し33件について、CLI の total_cost_usd をこの単価で検算しました。33件すべてが公式の定価と一致し、相対誤差はほぼ0でした。Claude の金額は、もともと公式の定価どおりだったことになります
• OpenAI は openai.com の料金ページの API タブにある、標準処理・コンテキスト272K未満の値です。ただし、GPT-6 Sol は確認した時点の料金ページに載っていませんでした。そのため、筆者が把握していた単価(入力$2.00 / キャッシュ入力$0.20 / 出力$10.00)を使っています。この単価は、公式ページで確かめられた値ではありません
• 最初は Codex を仮の単価で計算していました。記事の数字は、記録済みのトークン数から全試行を上の単価で計算し直したもの(bench/recost.mjs)です
• Codex は ChatGPT プランで使ったので、実際の請求はプランの定額です。表の Codex の金額は、同じ量を API で使った場合の換算額です

実装時間:親の開始から終了までの実時間から、子がレート制限で待った時間を引いたものです。子のレート制限は child.mjs が検知し、90秒待って再実行します。この待ち時間を waitMs として別に記録し、実装時間から除きます。ただし、親の CLI が内部で再試行したときの待ち時間は切り分けられていません。なお、上級版の有効な21試行すべてで、子の waitMs は0でした。

不具合率:エージェントからは見えない場所に置いた隠し受入テスト74件(計算31件・エラー31件・CLI 12件)のうち、不合格になった割合です。期待値はすべて手計算で作り、リファレンス実装が74件すべてに合格することを確認してあります。

結果(上級版・各構成3回)

値は平均で、括弧内は最小〜最大です。

構成	親 / 子	金額(USD)	内訳 親 / 子	トークン(千)	実装時間(分)	巻き戻し	不具合率	子が書いたテスト数
A	Opus / Opus	2.93 (2.75-3.27)	0.85 / 2.08	2125	11.4 (10.7-12.5)	0.3	0%	125, 100, 202
B	Sol / Sol	0.80 (0.66-1.06)	0.33 / 0.47	1663	8.7 (7.0-11.6)	0.7	1.4%(3回とも)※1	17, 16, 17
C	Opus / Sol	1.15 (1.03-1.35)	0.77 / 0.38	1255	7.8 (7.2-8.7)	0.0	0%	30, 16, 49
D	Opus / Luna	1.06 (0.86-1.41)	1.02 / 0.03	2377	14.9 (9.0-25.8)	1.3	0%	37, 37, 21
E	Sol / Opus	2.48 (2.38-2.63)	0.41 / 2.07	2278	11.6 (11.3-11.9)	0.7	0%	92, 106, 102
F	Sol / Sonnet	1.60 (1.37-2.05)※2	0.51 / 1.09	2549	15.8 (7.9-27.7)※2	1.7	0%	108, 190, 284
G	Sol / Luna	0.39 (0.32-0.46)	0.36 / 0.03	1818	9.4 (8.1-11.8)	1.7	1.4%(3回とも)※1	20, 10, 15

• ※1 B と G の不具合は、どれも同じ1件(L05:オプションをファイル名より前に書く形)です。L05 は、要件書に明記していない慣習を確かめるケースでした。実装の誤りというより、要件書に書いていないことを補えたかどうかの差です(考察の2を参照)。
• ※2 F の3回目は、実装時間と状態を手作業で補正しています。親は約28分で最終報告まで書き終えていました。しかし、子が起動した標準入力待ちのプロセス(python -)が残って出力パイプを握っていたため、親の終了を検知できず、90分のタイムアウト扱いになっていました。そこで、status を timeout から completed に手で書き換え、実装時間は最終報告(summary.json)を書き込んだ時刻までで補正しました(90.9分 → 27.7分)。この27.7分には、子のタイムアウト(10分)2回分の約20分が含まれます。その2回分のトークンと金額は計上されていないため、F の金額は実際より少なく出ています。
• 「子が書いたテスト数」は、最終状態でランナーが node --test を実行したときの合格件数(ownTests.pass)です。子の自己申告ではありません。
• 金額は API 料金による換算額です(内訳は平均。GPT-6 Sol は筆者が把握していた単価)。Codex は ChatGPT プランで使ったので、実際の請求はプランの定額です。

集計スクリプトが出した試行ごとの明細から、不合格が出た行を抜き出します(列:試行 | 状態 | USD | 分 | 巻き戻し | 受入 | 不合格ケース)。

| invoice-advanced-B-r1-20260929T073507 | completed | 0.6657 | 7.61 | 0 | 73/74 | L05 オプションが先でも可 |
| invoice-advanced-B-r2-20260929T092630 | completed | 0.6648 | 7.02 | 0 | 73/74 | L05 オプションが先でも可 |
| invoice-advanced-B-r3-20260929T103114 | completed | 1.0566 | 11.59 | 2 | 73/74 | L05 オプションが先でも可 |
| invoice-advanced-G-r1-20260929T084608 | completed | 0.4626 | 11.81 | 2 | 73/74 | L05 オプションが先でも可 |
| invoice-advanced-G-r2-20260929T101033 | completed | 0.3242 | 8.12 | 1 | 73/74 | L05 オプションが先でも可 |
| invoice-advanced-G-r3-20260930T021443 | completed | 0.371 | 8.13 | 2 | 73/74 | L05 オプションが先でも可 |

ほかの15試行は、すべて74/74で合格しました。

考察

1. 総合でいちばん良かったのは C(親 Opus / 子 Sol)

C は3回とも、巻き戻し0回・不具合0%でした。実装時間は平均7.8分で7構成中いちばん短く、ばらつきも7.2〜8.7分と、E(11.3〜11.9分)に次いで小さく収まりました。1回ごとに見ると、最も速かったのは B の2回目(7.02分)です。

金額は平均1.15ドルでした。不具合0%の構成の中では、D(1.06ドル)に次いで2番目に安く、差は約0.1ドルです。C の1回目を内訳で見ると、親 Opus が約0.92ドル(14ターン)、子 Sol が impl と test の2回で約0.43ドルでした。親の自己申告は「初回実装でレビュー重大指摘なし、テスト30件全件合格」でした。

2. L05 は、要件書に書いていないことを試すテストだった(設計側の反省)

不合格が出たのは B(Sol / Sol)と G(Sol / Luna)だけです。6試行すべてが、同じ1件(L05) で落ちました。L05 は、CLI でオプションをファイル名より前に書く形(--rounding floor file.json)を受け付けるかどうかを見るケースです。

ここは正直に書いておきます。要件書6章に書いた CLI の書式は、次の1行だけでした。

node src/cli.js <入力JSONファイルのパス | -> [--rounding <floor|round|ceil>]

「オプションはファイル名より前に書いてもよい」とは、どこにも書いていません。一方で、隠し受入テストの L05 はその形を正解として求めていました。つまり L05 は、要件書に明記していない一般的な CLI の慣習(オプションの位置は自由)を、隠しテストで試していたことになります。これは、検証を設計した私たちのテスト設計の甘さです。

そのうえで、事実として観察できたのは次の点です。

• 親が Opus の C・D では、子が Codex でも6試行とも L05 に合格した
• 子が Claude の E・F では、親が Sol でも6試行とも L05 に合格した
• 親 Sol + 子 Codex の B・G では、6試行とも L05 に不合格だった

B・G の不合格は、実装の不具合というより、要件書に書いていない慣習を、仕様書や実装の段階で補えたかどうかの差と見るのが妥当だと考えています。実際に B・G の有効な6試行すべての cli.js に --rounding floor <ファイル> の順で渡してみると、どれも ERROR: INVALID_INPUT(終了コード2)を返しました。書式どおり「ファイル名が先」の順番だけを受け付ける作りになっていました。ただし、どの段階で補われたのか(親の仕様書か、子の実装か)も突き合わせていないので、原因は断定できません。各3回という少ない回数での観察でもあります。

B・G でも、親のレビューと子が書いたテストは通っていました。たとえば B の1回目は、親の自己申告が「17件のテストがすべて成功」で、巻き戻しは0回です。ここから得た学びは2つあります。

• 要件書に書いていないことは、モデルの補い方しだいで結果が割れる。今回の場合、本来は要件書に書き切るべきでした
• エージェントが「完了」と報告していても、その判断は、自分たちが読んだ仕様の範囲の中での話です

3. 費用は、子が Luna なら親のモデルでほぼ決まる

費用の順位は、G(0.39ドル)< B(0.80)< D(1.06)< C(1.15)< F(1.60)< E(2.48)< A(2.93)でした。

いちばん安いのは G ですが、L05 に3回とも不合格でした。不具合0%の構成の中で最安は D(1.06ドル) で、C(1.15ドル)とほぼ同額です。

子を Luna にした D・G では、子の金額が1試行あたり平均約0.03ドルでした。差し戻しが増えても、子の費用はほぼゼロです。そのため費用は親のモデルでほぼ決まり、親 Opus の D は約1.0ドル、親 Sol の G は約0.4ドルになりました。親だけで見ると、Opus は0.8〜1.0ドル、Sol は0.3〜0.5ドルの範囲です(構成ごとの平均)。

一方で、子 Luna では差し戻しが増えました。巻き戻しは D が平均1.3回、G が平均1.7回です。

D の3回目は25.8分かかり、ばらつきが大きくなりました。記録からわかるのは、子4回の実行時間が合計8.9分で、残りの約17分は親の側でかかっていたことです。親のターン数は30で、ほかの2回は16ターンでした。親の中で何に時間を使ったかは調べていません。この試行で親が残した自己申告は「実装は初回で仕様どおり。テストの網羅不足を2回差し戻し」です。今回の「巻き戻し」には、実装の不具合だけでなく、テストが足りないことによる差し戻しも含まれる点に注意してください。

4. 子 Claude はテストを厚く書く

子が Claude の構成(A・E・F)では、子が書いたテストは92〜284件でした(最大は F の3回目の284件)。子が Codex の構成では10〜49件です。ただ、16件(C の2回目)でも284件(F の3回目)でも、受入テストは74/74でした。手元の検証では、テストの件数だけでは品質を判断できませんでした。

5. 子が Claude の構成は高い

高いほうから A(2.93ドル)、E(2.48ドル)、F(1.60ドル)で、上位3つがすべて子 Claude の構成でした。子の分だけで、A と E は約2.1ドル、F は約1.1ドルです。ほかの構成の子(0.03〜0.47ドル)よりはっきり高くなっています。

結論(この課題・この条件で)

• 正確さ・速さ・費用のバランスで選ぶなら C(親 Opus / 子 Sol)。不具合0%・巻き戻し0回・平均最短の7.8分で、費用も D とほぼ同じです
• 不具合0%のまま費用を抑えるなら D(親 Opus / 子 Luna)。ただし巻き戻しは平均1.3回で、時間のばらつき(9.0〜25.8分)は覚悟が必要です。いちばん安いのは G(0.39ドル)ですが、L05 は3回とも不合格でした
• 要件書の曖昧な点は、構成によっては最後まで補われずに残る。今回は、親 Sol + 子 Codex の組み合わせで3回とも残りました

EC-CUBE や Web アプリの開発にどう組み込むか

ここからは、EC-CUBE のカスタマイズや Go / React での Web アプリ開発に、この親子エージェントの体制を取り入れるならどう設計するか、という実装者の目線での案です。どれも今回の検証の範囲を超えた提案です。EC-CUBE は PHP で、Go や React も今回の課題とは言語が違います。Node.js の小さな課題で得た傾向が、そのまま当てはまるとは限りません。

分担の設計

• 仕様書を書く親には、上位モデルを置く。今回の6試行では、子が同じ Codex でも親を Opus にすると、要件書に書いていなかった L05 の点も補われていました。EC-CUBE でいえば、プラグインの仕様やカスタマイズ仕様を固める役に費用をかけるのが良いと考えています
• 子は、定型的な実装から軽量モデルを試す。子 Luna でも、親が Opus なら不具合0%でした(D)。子の費用は1試行あたり約0.03ドルで、費用はほぼ親の分だけになります。ただし、差し戻しが増えて時間がぶれることは見込んでおきます
• Go のバックエンドと React のフロントエンドのように層が分かれる構成では、親が API の仕様(入出力・エラーコード・チェック順)を先に固め、層ごとに別々の指示ファイルで子へ渡す形が自然だと考えています。今回の要件書は、エラーの優先順位は細かく書いた一方で、CLI の引数の順序は書いていませんでした。そこがまさに構成による差として出ました。要件書に書いていないことは、モデルの補い方しだいで結果が割れます。「当たり前」だと思うことも、要件の段階で書き切っておくべきでした
• 子は毎回まっさらにして、必要な情報をすべて指示ファイルに書かせる。子は過去の文脈に頼れないので、親の仕様書の質がそのまま成果物に出ます。逆に言えば、仕様書をレビューすれば品質の見通しが立ちます

品質:エージェントから見えない受入テストを持つ

B・G では、親のレビューも子のテストも通っていました。エージェントの自己申告とは別に、隠し受入テストを持っておく意味はあったと考えています。ただし今回の L05 のように、隠しテストが求める内容は、要件書にも書いておくべきです。そうしないと、テストが測っているのが「実装の正しさ」なのか「書いていないことの推測力」なのか、区別がつかなくなります。

• 送料・税・ポイント・クーポンのように金額が絡む処理は、人が手計算で作った期待値の受入テストを、エージェントが見られない場所に置く
• EC-CUBE で購入フローや金額計算の処理をカスタマイズするなら、「端数」「境界値(送料無料になる金額ちょうど)」「エラーの優先順位」「CLI やバッチの引数の順序」を、要件書とテストの両方に入れておく
• エージェントが自分で書いたテストの件数だけでは、品質を判断できない(今回は、16件でも284件でも受入テストは74/74でした)

費用

• 1機能あたり約0.4〜3ドルという数字は、この小さな課題を API 料金で換算した値です。料金が改定されれば、順位が入れ替わる可能性があります
• 費用の大部分は、上位モデルを置いた側から出ます。子に Claude を置くと子の分が1〜2ドル台になり、子に Luna を置くと子の分はほぼゼロでした
• 子の呼び出しを1か所に集めておくと(今回の child.mjs のように)、フェーズ別・モデル別の費用をそのまま集計できます。見積もりや、モデルを切り替えるかどうかの判断材料になります

運用

• タイムアウトしたら、プロセスツリーごと止める。Windows では、エージェントの CLI だけを kill しても、その下で起動された孫プロセスが出力パイプを握ったまま残ることがあります。そうなると終了を検知できず、ジョブが終わりません(今回の F の3回目がこれに当たります。※2を参照)
• 標準入力を読む仕様があるアプリでは、エージェントが入力を渡さずにコマンドを試し、そのまま止まることがあります(F の3回目の python - がその例です)。指示ファイルに「標準入力を使う確認は、必ず入力を渡して行う」と書いておくと防げる可能性があります(未検証です)

セキュリティ

• 承認なしモードは、専用の作業フォルダ、できれば使い捨ての環境でだけ使う。本番の EC-CUBE 環境や、実際の顧客データ・API キーがある場所では動かさない
• 子から孫への再委任を禁止する(今回は環境変数を空にして防ぎました)など、エージェントに渡す権限はできるだけ小さくする

まとめ

• 請求書計算(上級版)を題材に、親子エージェントのモデル組み合わせ7通りを、各3回試しました
• 親 Opus 5.5 / 子 GPT-6 Sol(C) が、不具合0%・巻き戻し0回・平均で最短の7.8分・1.15ドルで、総合的にいちばん良い結果でした
• 不具合0%の構成の中で最安は D(1.06ドル)で、C とほぼ同額です。いちばん安いのは G(0.39ドル)ですが、L05 に3回とも不合格でした。子 Luna の費用は1試行あたり約0.03ドルで、費用はほぼ親のモデルで決まります
• 子が Claude の構成(A・E・F)は、ほかより高くなりました
• 不合格は「親 Sol + 子 Codex」でだけ、同じ L05 で出ました。L05 は、要件書に書いていなかったことを試すケースでした。要件書に書いていないことは、モデルの補い方しだいで結果が割れるので、隠しテストで確かめることは要件書にも書き切るべき、というのが設計側としての反省です

最後に、この検証の限界です。

• 課題は小規模な1種類だけで、各構成3回しか試していません。大規模な開発でも同じ傾向になるとは限りません
• 金額は、2026-09-30時点の API 料金で換算した額です。料金の改定で順位が変わる可能性があります。GPT-6 Sol は確認時点の料金ページに載っていなかったため、筆者が把握していた単価を使いました。Codex は ChatGPT プランで使ったので、実際の請求はプランの定額です
• 推論の強さは Codex が medium、Claude が既定値で、完全にはそろえられていません
• F の3回目は、実装時間と状態を手作業で補正しており、金額の一部が計上されていません
• 実行環境側の不具合(子や親の停止、CLI の自動更新)で無効になった3試行は、集計から外して同じ構成で測り直しました。「有効な21試行」は、この測り直し後の数です

---

筆者について

株式会社エム・エー・ディー 取締役の村田です。エンジニア歴24年、EC-CUBEのカスタマイズを中心に、LaravelでのWebアプリやモバイルアプリの開発にも携わってきました。
現在はGoとReactを中心に開発しながら、EC構築の知見とAI駆動開発を組み合わせたDX支援に取り組んでいます。

• EC・AI活用のご相談:https://mad2007.co.jp/contact/
• 一緒に働くエンジニアを募集しています:https://mad2007.co.jp/recruit/