AIがコードを書く時代、人間は何を保証するのか———馬場さんと考える、開発者に求められる新しい責任と価値 - TECH PLAY

AIがコードを書く時代、人間は何を保証するのか———馬場さんと考える、開発者に求められる新しい責任と価値 - TECH PLAY
https://techplay.jp/event/997300
TECH PLAY X 2026-07-31 登壇資料

Transcript

1. AIがコードを書く時代、 人間は何を保証するのか 馬場さんと考える、開発者に求められる 新しい責任と価値 馬場 俊彰 netmarkjp.bsky.social TECH PLAY X 2026-07-31
2. 馬場俊彰（ばばとしあき） netmarkjp.bsky.social クラウド インフラ SRE 運用 モニタリング・オブザーバビリティ大好き トラブルシューティング・パフォーマンスチューニング大好き 株式会社X-Tech5 取締役CTO、株式会社iCARE技術顧問、 ICTトラブルシューティングコンテスト 会長 • SREaaS、SRE実現伴走支援/コーチ、チーム立ち上げ伴走 • 運用現場変革のリード/伴走支援、メンタリング・トレーニング • パフォーマンスチューニング、トラブルシューティングサービス Amazon著者ページ https://www.amazon.co.jp/~/e/B004Y4SUBY 2
3. わたしのポジション いろいろな顔があります - いちエンジニアとしての顔 エンジニアのマネージャーとしての顔 CTOとしての顔 取締役としての顔 ICT業界の一員としての顔 3
4. はじめに - 今日は答えがない話をします 一緒に考えましょう 着地がそれぞれ違っていいと思います ※今日は「AI」は「LLM」や「LLMを利用したAIエージェント」の意味で使います 4
5. AIがコードを書く時代に、 「開発者」は職業として成立し続けるか？ 5
6. AIがコードを書く時代に、 「開発者」は職業として成立し続けるか？ 考えるポイントは… - 社会的に価値があるか 成立を許されるか どのくらい希少か どのくらい専門的か ➔「人間/AI/プログラムの特性」を確認して 「負っている責任」と、「提供している価値」を整理してみる 【以降の流れ】 人間/AI/プログラムの特性について 負っている責任について 提供している価値について 6
7. 人間/AI/プログラムの特性について • 人間/AI/プログラムの特性について ◯ 負っている責任について ◯ 提供している価値について 7
8. 【それぞれの特性】 人間 AI（LLM） プログラム 確実に繰り返す 不可能 不可能 可能 複製/スケールアウト 困難 容易 容易 疲れ あり なし なし 柔軟性 あり（大） あり（中） なし 狭い文脈理解 あり あり なし 広い文脈理解/暗黙知対応 可能 不可能 不可能 可能だが制御できない（モデ 自発的成長（期待値向上） 可能だが制御 しづらい ル更新、自己更新による指標最 適化） なし 外部からのアプローチによ る期待値向上 可能だが制御 しづらい 可能で比較的制御しやすい 手をかけたことだけできる ようになる（バージョンアップ） 責任を負うこと できる （プロンプトやハーネスの更新） できない ➔提供者（最終的に人）が負 う できない 8 ➔提供者（最終的に人）が負う
9. 【それぞれの特性】 人間 AI（LLM） プログラム 確実に繰り返す 不可能 不可能 可能 複製/スケールアウト 困難 容易 容易 疲れ あり なし なし 柔軟性 あり（大） あり（中） なし 狭い文脈理解 あり あり なし 広い文脈理解/暗黙知対応 可能 不可能 不可能 可能だが制御できない（モデ 自発的成長（期待値向上） 可能だが制御 しづらい ル更新、自己更新による指標最 適化） なし 外部からのアプローチによ る期待値向上 可能だが制御 しづらい 可能で比較的制御しやすい 手をかけたことだけできる ようになる（バージョンアップ） 責任を負うこと できる （プロンプトやハーネスの更新） できない ➔提供者（最終的に人）が負 う できない 9 ➔提供者（最終的に人）が負う
10. 【それぞれの特性】 人間 AI（LLM） プログラム 確実に繰り返す 不可能 不可能 可能 複製/スケールアウト 困難 容易 容易 疲れ あり なし なし 柔軟性 あり（大） あり（中） なし 狭い文脈理解 あり あり なし 広い文脈理解/暗黙知対応 可能 不可能 不可能 可能だが制御できない（モデ 自発的成長（期待値向上） 可能だが制御 しづらい ル更新、自己更新による指標最 適化） なし 外部からのアプローチによ る期待値向上 可能だが制御 しづらい 可能で比較的制御しやすい 手をかけたことだけできる ようになる（バージョンアップ） 責任を負うこと できる （プロンプトやハーネスの更新） できない ➔提供者（最終的に人）が負 う できない 10 ➔提供者（最終的に人）が負う
11. 負っている責任について ◯ 前提: 人間/AI/プログラムの特性について • 負っている責任について ◯ 提供している価値について 11
12. 遂行責任 / 結果責任 / 説明責任 遂行責任： そうすべしと決まっていること、そうすべきとわかって いることをきちんと果たす 結果責任： 諸々の結果としてどうなっているべしと決まっている こと、どうなっているべきと決まっていることを実現する 説明責任： どのように状態が結実したかの過程や機序を、その時々の 判断や行動の決定要因や基準とともに解説できる 遂行責任 結果責任 説明責任 メンバー エグゼク 12 ティブ
13. 責任を負うこと 一般に、結果を実現するための必要十分で適切な活動を果たすこと ➔必要十分かの判定は、妥当性を利用者が納得すること ➔必要十分かの判定は、妥当性を関係者が納得すること ➔必要十分かの判定は、妥当性を社会が納得すること 2026年半ばの現時点では、対外的な法的責任は法人が負うにせよ、最終的に責任を引き 受けることができるのは自然人のみ ➔職位・裁量・権限の形式と実態を以て外形的に判断される その中で、開発者（達）が負っている責任は？ ➔高度専門職なので、メンバーレベルであっても遂行責任だけではない ※自社サービス/受託開発等の状況により大きく変わりますね 遂行責任 結果責任 説明責任 13
14. 改めて、開発者（達）が負っている責任について考える 遂行責任を果たす: すべきと定まったことをその通りに実施する、実施できる状態を保つ、の2側面 結果責任を果たす: 結果を実現する、合理的な注意義務を果たす、の2側面 説明責任を果たす: 説明可能な状態にする、説明し問答し改善する、の2側面 開発ツール、AI、開発プロセス、品質管理プロセス等で代替/充足できる？ ➔代替: システム・サービスが、受容される範囲で、合理的に満たせる？ 遂行責任 結果責任 説明責任 14
15. ところで、リテラシー＝読み書き能力について - リテラシー＝読み書き能力についての大原則 ➔読み書きの能力はセット 読めないと書けないし、書けないと読めない - - 読めなくなると書けなくなる 書けなくなると読めなくなる 文字もそう 自然言語もそう プログラミング言語もそう プログラムもそう 結果として出力しているものもそう - 例:給与計算プログラムなら給与明細、会計プログラムなら財務諸表 15
16. 提供している価値について ◯ 前提: 人間/AI/プログラムの特性について ◯ 負っている責任について • 提供している価値について 16
17. わたしたち開発者が提供している価値 有用性 効率を上げること、不可能を可能にする こと 客観的に 評価しやすい 保証 信頼性、可用性、キャパシティ、パフォー マンス、セキュリティ、持続性 比較的客観的に 評価しやすい 情緒的便益 興奮・快楽・快適・満足感・安心感… 客観的に 評価しづらい 自己表現的便益 自己主張の実現、自己肯定感… 客観的に 評価しづらい 機能的便益 - これらの「程度を設計」し「実現する」ことで価値を創出し、それを提供している いずれも「程度が高ければ高いほどよい」わけではない 情緒的便益や自己表現的便益は「競合と差別化すること」が求められることがあ る➔一般解はない。客観的評価しづらいので指標最適化もしづらい ※整理のためにAaker理論を参考にしていますが、あくまで分類の参考のみです 17
18. わたしたち開発者が提供している価値 有用性 効率を上げること、不可能を可能にする こと 客観的に 評価しやすい 保証 信頼性、可用性、キャパシティ、パフォー マンス、セキュリティ、持続性 比較的客観的に 評価しやすい 情緒的便益 興奮・快楽・快適・満足感・安心感… 客観的に 評価しづらい 自己表現的便益 自己主張の実現、自己肯定感… 客観的に 評価しづらい 機能的便益 - これらの「程度を設計」し「実現する」ことで価値を創出し、それを提供している いずれも「程度が高ければ高いほどよい」わけではない 情緒的便益や自己表現的便益は「競合と差別化すること」が求められることがあ る➔一般解はない。客観的評価しづらいので指標最適化もしづらい ※整理のためにAaker理論を参考にしていますが、あくまで分類の参考のみです 18
19. わたしたち開発者が提供している価値の解説 - ITIL 4等も参照して整理すると情報通信システムの価値には有用性と保証があ る 有用性は時短や不可能を可能に、という要素 保証は信頼性・可用性・キャパシティ・パフォーマンス・セキュリティ・持続性、とい う要素 いままでは、この有用性と保証の実現がソフトウェアエンジニアの専門性だった 有用性を正確に・迅速に実現すること、保証を適切に実現することが、ソフトウェ アエンジニアの腕の見せ所だった これらは、インターネットやクラウドサービスの普及でかなりハードルが下がり、 生成AIによってさらにハードルが下がった わたし個人は、有用性実現は特にAIが上手という実感がある 有用性と保証の設計もAIが参加可能。有用性の設計は、目的適合を客観指標で 評価しやすいぶん、AIの適用可能性が広いと考える。保証の設計は、可用性やコ ストなど各要素は客観計測できるが、「どの程度を保証するか」がトレードオフの 意思決定になるので客観評価だけでは決まらず、AIの適用可能性が（比較して） 狭いと考える 19
20. わたしたち開発者が提供している価値の解説 - - ウェブサービス開発でもファームウェア開発でもゲーム開発でも、開発者は手元 では「開発行為でお金を貰って」いる もう少し視野を広げると、これは「そのソフトウェアの利用者に対する価値提供」 でお金をもらっている 利用者が、ほとんどの場合はそのソフトウェアを通じて得られる便益に対して、 ごく稀にそのソフトウェア自体に、価値を感じ、お金を払っている これはブランディング/ブランド管理のAaker理論を参考にしているけれど、 Aaker理論自体はユースケースが異なるのでAaker理論として理解しないほう がここではスムーズ 機能要件を実現するのは機能的便益の実現で、非機能要件を実現するのも機能 的便益。機能的便益は客観的評価しやすく計測可能性が高い 有用性と保証はいずれも「機能的便益」 機能的便益/情緒的便益/自己表現的便益が完全に区切れているわけではない。 20 情緒的便益の快適さを支えるのは機能的便益のパフォーマンスだったりする
21. わたしたち開発者が提供している価値の解説 - 情緒的便益は興奮・快楽・快適・満足感・安心感等々。機能的便益が裏で支える面 はある 購買者から見て、自己表現的便益と情緒的便益は内発的な側面が大きく、機能 的便益は外発的（つまり客観的評価指標に基づく判断）が大きい 内発的/外発的はどちらかではなく両面を含む程度表現になる。またこれらは相 互に絡む たとえば非機能要件は特に情緒的便益（安心感）への転化が強い いまは具体からボトムアップで考えたけど、逆にトップダウンで考えるパターン もある トップダウンの一例で、例えばナラティブの世界観。これは共感→（自己表現的便 益の実現+情緒的便益の実現）→それを支える機能的便益という形 繰り返しになるけれど、機能的便益・情緒的便益・自己表現的便益は相互に影響 する 21
22. まとめ 22
23. 【それぞれの特性】 人間 AI（LLM） プログラム 確実に繰り返す 不可能 不可能 可能 複製/スケールアウト 困難 容易 容易 疲れ あり なし なし 柔軟性 あり（大） あり（中） なし 狭い文脈理解 あり あり なし 広い文脈理解/暗黙知対応 可能 不可能 不可能 可能だが制御できない（モデ 自発的成長（期待値向上） 可能だが制御 しづらい ル更新、自己更新による指標最 適化） なし 外部からのアプローチによ る期待値向上 可能だが制御 しづらい 可能で比較的制御しやすい 手をかけたことだけできる ようになる（バージョンアップ） 責任を負うこと できる （プロンプトやハーネスの更新） できない ➔提供者（最終的に人）が負 う できない 23 ➔提供者（最終的に人）が負う
24. 改めて、開発者（達）が負っている責任について考える 遂行責任を果たす: すべきと定まったことをその通りに実施する、実施できる状態を保つ、の2側面 結果責任を果たす: 結果を実現する、合理的な注意義務を果たす、の2側面 説明責任を果たす: 説明可能な状態にする、説明し問答し改善する、の2側面 開発ツール、AI、開発プロセス、品質管理プロセス等で代替/充足できる？ ➔代替: システム・サービスが、受容される範囲で、合理的に満たせる？ 遂行責任 結果責任 説明責任 24
25. わたしたち開発者が提供している価値 有用性 効率を上げること、不可能を可能にする こと 客観的に 評価しやすい 保証 信頼性、可用性、キャパシティ、パフォー マンス、セキュリティ、持続性 比較的客観的に 評価しやすい 情緒的便益 興奮・快楽・快適・満足感・安心感… 客観的に 評価しづらい 自己表現的便益 自己主張の実現、自己肯定感… 客観的に 評価しづらい 機能的便益 - これらの「程度を設計」し「実現する」ことで価値を創出し、それを提供している いずれも「程度が高ければ高いほどよい」わけではない 情緒的便益や自己表現的便益は「競合と差別化すること」が求められることがあ る➔一般解はない。客観的評価しづらいので指標最適化もしづらい ※整理のためにAaker理論を参考にしていますが、あくまで分類の参考のみです 25
26. 『開発者』は職業として成立し続けるか？ 社会的に価値があるか: 「遂行責任の遂行可能状態の保持」「結果責任の合理的な注意義務」「説明責任」 を果たすひとが必要なので、リテラシーのある誰かしらは必要 成立を許されるか: 何かやりすぎてAIや情報システム全体が社会から排斥されなければ許されそう 現状、さほど悲観していません: でも有用性実現の価値は下がる。保証実現の価値も下がるかも。 有用性実現の価値はAIとあまり関係なくて、（元々）競合や業界の成熟による 保証実現の価値は下がらないと思う。上がる可能性すらある。 でも「イマイチ保証」に社会が先に慣れてしまうとわからない。 （「AIが言うなら仕方がない」の社会的受容） 26
27. 『開発者』は職業として成立し続けるか？ されども「同じHow」は続けられないとは思う： ただし「同じHow」でずっと食っていけないのは昔からそう。 これは社会が常に変化しているのだから仕方がない。 AIをうまく使えると生存しやすい？： 「遂行責任の遂行可能状態の保持」「結果責任の合理的な注意義務」「説明責任」 を実現するために、機能的便益の保証を設計し継続的に実現できる人が必要。 AIと仕事をするのは「他人と仕事をする」のに似ている。 となると、全員が管理職的要素を今よりも強く持つことになる。 27
28. 周辺の話題 28
29. 周辺の話題 「とある個人の雇用継続」はまた別の話 - AIが直接雇用を奪うことは、いまのところ原理的におきない ➔雇用・解雇を決定するのは人間の意思決定による ➔「AI」でも「会社」でも「社会」でもなく決定した人 ➔意思決定をした人、そのひとに意思決定を迫る圧力をかけた人が要因 - 「XXX（なんらかの指標や他者の価値基準）のためには仕方がない」が判断軸なら、その役割は人 間である必要はない AIで代替されるのは「自己判断しない管理職」かもしれない 企業は収益追求マシーンだけど、同時に社会の公器である - バランスを決めるのは人だし、それを求めるのも人。それを評価するのも人 ルールも法律も社会も人が作るもの 例えば「AIで代替するから雇用を削減した企業・サービス」を選ぶのも、避けるの 29 も意思決定
30. グッとくる問い 30
31. グッと来る問い 1: 「ちょうどいい」は難しい/よくわからないがちですよね ➔あなたは自分が開発している対象について、購買者視点で受容可能な範囲で、品 質/保証を下げて他の指標を上げる具体的な品質の程度を判断/決定できますか？ 2: 「プログラミングの再定義」が話題です（品質管理軸への転換） ➔あなたはこの「再定義」が成立すると考えますか？ 3: 「プログラミング能力の再定義」が話題です（同上） ➔あなたは「（現在の意味での）書く能力」がなくなっても、最低限の機能的便益の実 現は可能だと考えますか？ ➔わたしたちは、機能的便益（有用性）、機能的便益（保証）、情緒的便益、自己表現的 31 便益、どこをどう組み合わせて提供することで食っていきましょうか？
32. グッと来る問い1 つま先まで・爪の先までの品質を提供できるか？ - AIだけでは「できない」 細部までに責任を負わないひと（典型的には上職者やコンサル）が、声高にAI推 進している側面は確かにある（ばばもこの顔がある） ただ、その立場の人にとっては、「細部まで責任を負わない」のは「人間のときも AIのときも同じ」 ここが対立や食い違いの大きな要因のひとつになっているのをよく見かける 32
33. グッと来る問い1 では、つま先まで・爪の先までの品質を提供すべきか？ - - - 前提: 大量生産品の品質管理は基本的に確率的に行い、それが社会に受け入れ られている ➔機能開発は大量生産とは異なるワンオフの取り組みだけれども、しかしAIに よって大量生産的になってきている（一点ものから注文住宅へ） つま先まで・爪の先までの品質に価値があるかどうかは、利用者がそれを基準に 買うかどうかにかかっている ➔求められないものを提供するのは基本的に過剰 「あったほうがいい」は「なくてもいい」でもある。「ないほうがいい」まである ➔安くてそれなり、安くてイマイチが選ばれるなら・選ぶなら品質は過剰 これは社会受容の話。つまり「わたしたち市民が決めていく」こと ➔あなたは自分が開発している対象について、購買者視点で受容可能な範囲で、品 質/保証を下げて他の指標を上げる具体的な品質の程度を判断/決定できますか？ 33
34. グッと来る問い2 読み書き能力が必要なのにAIだけが書いていたら、いずれ読む能力も失うのでは？ そうしたらAIやプログラムに責任を負うことができなくなるのでは？ - - 「書かなければいずれ読む能力も失う」は、程度の差はあるが原理的にYes 「書く」が再定義されて、AIの出力を決定論的に縛るための制約やハーネスが対 象になるという主張もある 「書く」の再定義は、細部にまで責任を負わないひと（典型的には上職者やコンサ ル、立ち上げや展開フェーズに携わる人材）が、声高にAI推進しているように見 える側面がある （ばばもこの顔がある） もし業界が自滅に向かっているとして、この流れは止めるべき？超えるべき？ ➔あなたはこの「再定義」が成立すると考えますか？ 34
35. グッと来る問い3 問い2から続けて、しかし敢えて逆に - - 【再】「書く」の再定義は、細部にまで責任を負わないひと（典型的には上職者やコ ンサル、立ち上げや展開フェーズに携わる人材）が、声高にAI推進しているよう に見える側面がある（ばばもこの顔がある） ただ、その立場の人にとって、「細部まで実現できないかもしれない」リスクは 「人間のときもAIのときも同じ」 なので「同程度の機能的便益」が実現できなくても「最低ラインの機能的便益」を 実現できれば問題ないという考え方もある ➔あなたは「（現在の意味での）書く能力」がなくなっても、最低限の機能的便益の実 現は可能だと考えますか？ ➔わたしたちは、機能的便益（有用性）、機能的便益（保証）、情緒的便益、自己表現的 35 便益、どこをどう組み合わせて提供することで食っていきましょうか？