技術的負債に向き合うConference2026 負債の返済か、作り直しか 2026.09.17 「作るもの」も「作りかた」もAIで変わった今、下した判断 取締役CTO 井坂 星南 

成功しているのに、リプレースする 売上成長中 ▶ 1→10のグロース局面 02 

成功しているのに、リプレースする 売上成長中 ▶ 1→10のグロース局面 ▼ それでも、既存プロダクトを リプレースする判断をした。 03 

プロダクトを畳んで やり直すという話ではない。 同じ顧客、同じ課題に対して、 より良いものを今後も作り続けるための判断。 

製造現場に経営視点で伴走する 製造業特化型AIスタートアップです。 

匠フォースAIエージェント 

普通の技術的負債は、普通にあった。 アーキテクチャ規約から外れたコード EOLした依存ライブラリ 複雑化してしまったロジック 一貫していない実装パターン 今まで通りの価値を出すだけでも、開発を遅くする負債 07 

AIが「作るもの」を変えた 

AIが変えたのは、機能ではなく「誰が仕事をするか」だった BEFORE 人がソフトウェアを操作して 仕事をする AFTER → AIが仕事そのものを進め、 人が確認・判断する 「AI機能を追加する」ではなく、体験設計そのものが変わる。 09 

見積業務の Before / After Before：人が状態を一つずつ作る 案件を開く ▶ 図面を見る ▶ 品目を作る ▶ 工程・原価を入力 ▶ 見積完成 After：AIが業務を進め、人が確認する ファイルを渡す ▶ AIが図面を理解 ▶ 品目構成を推論 ▶ 情報収集・見積案 ▶ 作成 ▲ 人が確認 ▶ AIに修正を指示 修正内容がフィードバックとして戻り、次の推論に反映される 10 

前提変更① ── 「ブラウザがある」ことを前提に責務を置いていた 人がブラウザで操作する世界 Browser ├─ 入力 見積計算 ├─ 再計算 ├─ AIがバックグラウンドで遂行する世界 → AI / Server 見積計算 ├─ 再計算 ├─ └─ ValidationBrowser が存在しない └─ Validation 「人がブラウザで仕事をする」という前提が切れた瞬間、 責務配置そのものが負債になった。 11 

前提変更② ── ドメインモデル AIが介在するドメインモデル これまでのドメインモデル 属性値 = 現在の値 → 値 推論した候補 ＋ 根拠 / 参照箇所 ＋ ＋ confidence 未確認 / 確認済み ＋ 修正履歴 ＋ AIが介在することで、現実世界にはなかった情報が ドメイン上の重要な概念になった。 12 

積み上げてきた「資産」が、変更困難な負債として立ち現れた 資産 UI・操作フロー API 業務ロジック データモデル 変更困難な負債 前提の変更 → UI・操作フロー API 業務ロジック データモデル コードが一夜にして悪くなったわけではない。 目指す世界が変わったことで、一夜にして負債として立ち現れた。 13 

技術的負債は「汚いコード」だけではない。 コードに埋め込まれた理解 ↓ ギャップ 現在の世界・現在の理解 新しく得た理解をコードへ反映しないと、 そのギャップが「利息」を生む。 Ward Cunningham の Technical Debt の考え方から 14 

では、既存プロダクト上で全部返済すればよいのでは？ 技術的には、できる。 でも、非連続は創出できない 

なぜ、既存改修だと時間がかかるのか 体験設計 データモデル ビジネスロジック UI AIが扱う中間状態 コードだけでなく、顧客の業務そのものも既存プロダクトに適応している。 既存顧客が今使っているもの 今の画面 今の操作方法 今の業務フロー 今のデータ構造 既存運用を維持しながら変えるために必要なこと 古い体験も残す 新しい体験も作る 両方が成立するデータ構造にする 顧客を徐々に移行させる 顧客側の業務変更・学習も支援する 最終形を作るだけでなく、 「途中状態を成立させ続ける仕事」が増える。 16 

連続的な改善では、必要な非連続を生めなかった 値価客顧 短期間で作りたい価値差 返済でも、たどり着ける。 時間 でも、その進み方では必要な速度で非連続を生めなかった。 17 

AIが「作り方」も変えた 

AI時代に突然、良い設計の定義が変わったわけではない。 実際にAIコーディングしているエンジニアに、 どこで速度が止まっているかを聞いた。 ① UIと業務ロジックの強い結合 ② 独立した開発環境を作りにくい AIが変更後の挙動を実行・検証しきりにくい 複数Agentを並列に走らせにくい 19 

① UIと業務ロジックの強い結合 Reactの状態・レンダリング × 見積計算ロジック AIがコードを書く ▶ 実行して挙動を見る ▶ 複雑な画面状態まで 再現しないと確認できない 観点 AI中心で欲しい構造 既存プロダクト 業務ロジック UIから独立して実行・テストできる UI・状態管理・レンダリングと強く結合 検証 変更→テスト→修正をAI自身で閉じられる ブラウザ上の複雑な状態まで見ないと確認しにくい AIが変更後の挙動を、自分で実行・検証しきれない。 20 

② 独立した開発環境を作りにくい クラウド依存 / ローカル再現困難 / 環境を複製しにくい 実装は並列化できる 複数Agentへ別々のタスクを渡せる 実行・検証は直列化する タスク単位でDB・アプリ環境を独立させられない 観点 AI中心で欲しい構造 既存プロダクト 開発環境 並列性 ローカルで再現でき、使い捨て可能 Agentごとに独立環境を立ち上げられる クラウド依存が強く、完全なローカル再現が難しい DB・アプリ環境をタスク単位で複製しにくい AIが速くても、実行・検証環境が直列なら、開発全体は速くならない。 21 

同じAIが、2種類の負債を別の形で重くした プロダクト側 開発側 AIによる変化 AIが業務を遂行できる AIがコードを書ける 以前の前提 既存コードに起きたこと 人が操作する 昨日まで負債ではなかった前提が負債化 人が理解して実装する 昔からあった負債の利息が上昇 同じAIが、片方では新しい負債を顕在化させ、 片方では既存負債の利息を上げた。 22 

AIは技術的負債に3方向から作用した 02 新しく顕在化させた 01 返しやすくした 従来型負債の返済コスト ↓ プロダクト前提の失効 AI 03 利息を上げた 既存の設計負債の重要度 ↑ 同じAIが、負債を軽くもするし、増やしもするし、重くもする。 23 

返済か、リプレースか 

返済ではなく、 既存プロダクトをリプレースする。 

ただし、作り直せば負債が消えるわけではない 既存を維持することで払い続ける コスト・リスク 開発速度の恒常的な低下 重要領域の障害リスク 互換性制約 非連続な価値提供の遅れ リプレースによって新しく引き受ける コスト・リスク 機能回帰 データ移行 新旧の乖離 二重運用 移行が終わらないリスク 負債をゼロにする判断ではない。 どちらの負債を持つかの判断。 26 

「作り直せば速い」だけでは判断しない。 リスク どう抑えるか 機能回帰 データ移行事故 必要機能を満たした顧客から段階移行 全オブジェクトを事前に洗い出し、新旧マッピング。移行不能を先に明示 業務停止 同一顧客でも新旧併用期間を持ち、問題があれば戻す 新旧の乖離 移行が終わらない 二重運用を恒久化せず、移行単位と終了条件を明確にする 旧版停止までをリプレース計画に含める 失敗したときの損失を、どこまで限定できるか。 27 

Big Bangではなく、顧客ごとに移行する Big Bang 今回 旧システム ────────× ↓ 新システム 旧システム ──────────────── ↓ 顧客ごとに移行 新システム ─────────── ↑ 問題があれば戻せる 「リプレースする」という大きな意思決定を、 実行単位では小さく・可逆にする。 28 

期待値が違う顧客を、同じ順番で移行しない。 新プロダクト前提で合意した顧客 既存顧客 先に導入 最後に移行 「開発中で、これから完成度を上げる新プロダクト」 新プロダクト前提で合意した顧客から導入 ▶ 「今までできていたことが、一つでも悪くなると改悪」 必要機能・精度・安定性を高める ▶ 既存顧客へ移行 29 

ゼロリスクな選択肢はなかった。 リプレースするリスク リプレースしないリスク 大きいが、分割できる / 戻せる / 終了条件を持たせられる 継続的で、終了条件を持ちにくい 機能回帰 データ移行事故 新旧の乖離 移行が終わらない 開発速度低下を払い続ける 重要領域の障害リスクを払い続ける 必要な速度で次の価値へ届かない リプレースのリスクは大きいが、 リプレースしないリスクの方が大きく、制御しにくかった。 30 

恒常的な「利息」は、速度低下率ではなく現場の摩擦から見る 約25 既存改修側で払い続ける摩擦 リプレース側の移行負債 二重運用 人月 + 移行基盤 + 顧客移行 + 旧版停止 15人チーム × 24か月 総開発量 360人月 恒常的な速度低下 2年間の追加コスト 相当 ハーネス不足で、AIの変更を人が広く確認する 負債のある領域ほど、AI出力の修正・やり直しが増える 変更が局所化されず、周辺の壊れ方を人が追う 暗黙知を毎回説明する / AIが再探索する 5% 18人月 7% 25.2人月 10% 36人月 20% 72人月 速度低下率を無理に推計せず、 「1回の変更で何が余計に起きているか」を現場で観測する。 エンジニアインタビューで実際に出たボトルネック ① FEの複雑な状態・レンダリングと見積ロジックが結合 ② クラウド依存が強く環境をローカルで再現・複製しにくい 31 

これは「リプレースが正解」という話ではない。 条件 返済・漸進改善が向く リプレースを検討しやすい 必要な変化速度 移行途中の価値 漸進改善でも間に合う 各段階でも顧客価値が成立する 漸進では必要な速度に間に合わない 途中状態では狙う価値が成立しにくい 顧客とのインターフェース 表面を維持して内部を交換できる 操作・業務フロー自体を変えたい 新システムの実行可能性 旧システムの終了可能性 作り直しコストが現実的でない 旧版を畳み切れない 新規構築の速度・コストが許容できる 終了条件を具体的に描ける 5つ揃ったらリプレース、というスコアリング表ではない。 32 

第4幕 この経験から、 次にどう設計するか 今回の経験を振り返って、今後の設計で意識したいこと。 

前提には、寿命がある。 当時として妥当だったコードでも、 世界の理解が変われば負債になり得る。 無自覚だったのは、設計ではなく、前提の寿命だった。 

未来は当てられない。 だから、当てにいかない。 未来を予測するのではなく、 前提が外れたときに交換しやすい構造にしておく。 

設計原則は、分離の方法を助けてくれる。でも、どこに変更容易性のコストを払うかは、設計 者が選ぶ。 役割 設計原則 どう分離するかを助ける 設計判断 どこに変更容易性のコストを払うかを選ぶ 全部を交換可能にすればいいわけでもない。分離そのものにもコストがある。 未来が外れたときに、何を交換しやすくしておくか。 その選択自体が、設計判断なのだと思う。 36 

技術的負債に向き合うConference2026 負債の返済か、作り直しか 2026.09.17 「作るもの」も「作りかた」もAIで変わった今、下した判断 取締役CTO 井坂 星南