Webアプリ設計における役割分担とAI活用の責務設計
はじめに
この章では、Webサービス設計における役割分担を学びます。ここでいう役割分担とは、肩書きを並べることではなく、誰が何を決め、誰が何を作り、誰が何を守るかを整理することです。
Atlassian は、プロダクトマネージャーを、ユーザー・ビジネス・技術のバランスを取りながら、戦略、ロードマップ、機能を定義する役割だと説明しています。
Google SRE は、SRE を、ソフトウェア工学を用いて信頼性と運用を支える役割として位置づけています。OWASP も、安全な開発には役割と責任の明確化が必要だとしています。
この章では、企画、設計、実装、品質保証、運用、セキュリティという基本的な役割を整理したうえで、AI が置き換えやすい部分と、人が最終責任を持つべき部分を分けて考えます。
さらに、AI を使った開発をどう信頼性ある形で進めるか、そして「AI を使っています」と伝えることが、なぜ場合によっては信頼や価格評価を下げうるのかを、シグナリングゲームの考え方で説明します。
NIST は trustworthy AI に、有効性・安全性・セキュリティ・説明可能性・透明性・説明責任などが含まれると整理しています。OECD も、人間中心の価値、透明性、説明責任、堅牢性、人による監督を重要原則としています。
この章で学ぶこと
- Webサービス設計で役割分担が必要な理由
- 代表的な役割と責務
- 小規模開発と大規模開発の違い
- AI に置き換えやすい部分と置き換えにくい部分
- AI を使う場合の信頼性担保
- AI 利用開示が信頼や価値に与える影響
1. なぜ役割分担が必要なのか
役割分担が必要なのは、Webサービスが一つの視点だけでは成立しないからです。利用者の課題を理解する視点、使いやすさを設計する視点、実装する視点、品質を確かめる視点、公開後に安定稼働させる視点は、それぞれ異なります。
MDN は Web 学習を、フロントエンド、サーバーサイド、テスト、デプロイなど複数の領域に分けて扱っており、これらが別々の責務として存在することを示しています。
役割分担とは、人を細かく分断することではありません。責務を分け、連携しやすくすることです。小規模開発では一人が複数役割を兼ねることがありますが、その場合でも頭の中では責務を分けて考える必要があります。
プロダクトの方向性を決める責任、進行を管理する責任、体験を設計する責任、実装する責任、品質を守る責任、安定運用を守る責任は、本質的には別物です。
flowchart TB
A[課題定義] --> B[価値判断]
B --> C[体験設計]
C --> D[実装]
D --> E[品質確認]
E --> F[公開・運用]
F --> G[改善]
1-1. 役割分担をしないと何が起こるか
役割分担が曖昧だと、次のような問題が起こります。
- 何を優先すべきか決まらない
- 使いやすさより実装都合が優先される
- 品質確認が「作った本人の感覚」だけになる
- 障害時に誰が責任を持つのか曖昧になる
- セキュリティや運用が後回しになる
1-2. この章で扱う役割の範囲
この章では、次の役割を扱います。
- 企画・プロダクト側
- 進行管理側
- デザイン側
- 開発側
- 品質保証側
- 運用・信頼性側
- セキュリティ側
- AI 支援と人間監督
まとめ
- 役割分担は、人を分けることよりも、責務を分けることが本質です。
- 人数が少なくても、役割の視点は必要です。
- 役割分担が曖昧だと、品質、速度、信頼性のすべてが不安定になります。
2. 企画・プロダクト側の役割
企画・プロダクト側は、何を作るべきかを決める役割です。Atlassian は、プロダクトマネージャーが product strategy、roadmap、features を定義し、ユーザー、ビジネス、技術のバランスを取ると説明しています。つまり、実装の前に「どの課題を、なぜ、どの順で解くか」を決める役割です。
一方で、プロジェクトマネージャー的な役割は、どう進めるかを管理します。Atlassian は、product manager と project manager の違いとして、前者は vision and strategy、後者は timelines and execution を担うと整理しています。
2-1. プロダクトマネージャー的な責務
- 誰の課題を解くか決める
- 何を優先するか決める
- 何を作らないか決める
- 利用者価値と実現可能性を調整する
2-2. プロジェクトマネージャー的な責務
- 誰が何をいつ進めるか整理する
- 抜け漏れや遅延を管理する
- 関係者の調整を行う
- リスクを早く見つける
まとめ
- 企画側は「何を作るか」を決めます。
- 進行管理側は「どう進めるか」を支えます。
- この二つを混同すると、価値判断と進行判断がぶつかりやすくなります。
3. デザイン側の役割
デザイン側の役割は、見た目を整えることだけではありません。利用者が迷わず理解し、目的を達成できる体験を設計することが中心です。Atlassian の product management 解説でも、UX をプロダクトの重要な構成要素として扱っています。
3-1. UX 設計の責務
- 利用者の行動を整理する
- どこで迷うかを考える
- どうすれば目的達成しやすいかを考える
3-2. UI 設計の責務
- 情報をどう配置するか決める
- 何を先に見せるか決める
- 操作しやすい見た目にする
3-3. 情報設計の責務
- 何を、どの順で見せるか整理する
- どこで入力させるか決める
- どこで判断を促すか設計する
まとめ
- デザインは装飾ではなく、理解と操作の設計です。
- UX、UI、情報設計を分けて考えると、体験の質を上げやすくなります。
- 開発都合だけで決めると、利用者にとって使いにくいサービスになりやすいです。
4. 開発側の役割
開発側は、設計されたものを実際に動く形へ落とし込む役割です。MDN は Web 技術を HTML、CSS、JavaScript、サーバーサイド、API などの複数要素に分けて説明しており、開発側でも責務が自然に分かれることが分かります。
4-1. フロントエンドの責務
- 画面を作る
- 入力や表示を制御する
- クライアント側の体験を実装する
4-2. バックエンドの責務
- 業務ロジックを実装する
- 認証・認可・データ処理を担う
- API やサーバー側処理を設計する
4-3. データ設計の責務
- 保存構造を決める
- 整合性を保つ
- 検索や更新を支える
まとめ
- 画面、処理、保存は責務が違います。
- 開発側の役割分担は、見た目よりも責務の違いから生まれます。
- どの技術を使っても、この三つの視点は大きく変わりません。
5. 品質保証とテストの役割
作ることと、正しいかを確かめることは別です。MDN のワークフロー記事では、新しいコードで既存機能を壊さないためのテストが必要だと説明しています。つまり、品質保証は「最後に少し確認する作業」ではなく、独立した責務です。
5-1. QA 的な責務
- 想定通りに動くか確認する
- 想定外で壊れないか確認する
- 正常系だけでなく異常系も見る
5-2. テスト責任の分担
- 開発者が行う確認
- QA が行う確認
- 自動テストと手動確認
まとめ
- 作った本人の視点だけでは見落としが出やすいです。
- 品質保証は、別の視点で確かめる役割です。
- テスト責任を曖昧にすると、品質が安定しません。
6. 運用・信頼性の役割
公開後に動き続ける状態を保つことも、重要な役割です。Google SRE は、SRE を、ソフトウェア工学を用いて大規模システムの運用を支え、手作業で行われていた運用を自動化する考え方として説明しています。
6-1. 運用側の責務
- 監視する
- 障害に対応する
- ログを確認する
- デプロイや設定変更を支える
- 継続利用に耐える状態を保つ
6-2. SRE 的な責務
- 信頼性を高める
- 可用性を維持する
- 運用の自動化を進める
- 手作業を減らす
まとめ
- リリース後の安定性は、サービス価値そのものです。
- 運用は開発の後工程ではなく、同じサービス設計の一部です。
- 信頼性は偶然ではなく、役割として守る必要があります。
7. セキュリティの役割
OWASP は、安全な開発には requirements、design、implementation、verification、operation を通じた責任の明確化が必要だとしています。つまり、セキュリティは一人の専任者だけの問題ではなく、各工程に埋め込む観点です。
7-1. セキュリティ側の責務
- 守るべき情報を整理する
- リスクを見つける
- 権限や境界を設計する
- 実装と運用に監督視点を入れる
7-2. 専任がいない場合でも必要な視点
- 要件段階で守る対象を決める
- 設計段階で認証・認可を考える
- 実装段階で入力検証や依存更新を行う
- 運用段階で監視と対応を続ける
まとめ
- セキュリティは後付けにしにくい領域です。
- 役割として独立した視点を持つほど、事故を減らしやすくなります。
- 専任者がいなくても、責務自体は消えません。
8. AI時代における役割分担の再設計
AI が登場しても、役割分担そのものは消えません。変わるのは、作業の一部が AI に代替・補助されることと、人が担うべき責任の重みが増すことです。
NIST は trustworthy AI を、valid and reliable、safe、secure and resilient、accountable and transparent、explainable などの性質を備えるものとして整理しています。OECD も、人による監督、透明性、説明責任を重視しています。
8-1. AI に置き換えやすい部分
AI が比較的得意なのは、反復性が高く、下書き価値がある作業です。
- 要件整理のたたき台作成
- 会議メモや議事録の要約
- 仕様書の下書き
- 画面文言や FAQ の初稿
- コード補完や定型実装
- テストケース案の作成
- ログ分類や問い合わせ分類
8-2. AI に置き換えにくい部分
一方で、次のような役割は人の責任が残りやすいです。
- 最終的な優先順位判断
- 利用者理解に基づく意思決定
- リスク受容の判断
- 納品や公開の承認
- クライアントへの説明責任
- ブランドや信頼の管理
8-3. AI を組み込んだ役割分担の考え方
AI を使うときは、AI が下書きし、人が検証し、人が責任を持って確定するという流れが基本になります。高リスク領域ほど、人の関与を強めるべきです。
これは NIST AI RMF が、AI の trustworthiness を設計・開発・利用・評価の全体で管理すべきだとする考え方とも一致します。
まとめ
- AI が代替しやすいのは下書き・補助・分類・定型化しやすい作業です。
- AI に置き換えにくいのは最終判断、責任、説明、リスク受容です。
- AI を入れても役割分担は消えず、むしろ監督と検証の役割が強くなります。
9. AI を用いた開発における信頼性担保
AI を使ったからといって、自動的に品質が上がるわけではありません。NIST は、AI リスクを理解し管理することが trustworthiness を高め、その結果として public trust の向上につながるとしています。
つまり、信頼性担保は「AI を使うかどうか」ではなく、AI をどう管理するかにかかっています。
9-1. なぜ信頼性担保が必要なのか
- AI 出力は常に正しいとは限らない
- 文脈や入力で品質が変動する
- 顧客は最終責任を AI ではなく提供者へ求める
9-2. 信頼性担保のために必要な要素
- 人間によるレビュー
- 根拠や出典の確認
- テストと検証
- ログと監査可能性
- 権限管理
- 高リスク領域での人間監督
9-3. 「AIを使った」と「AIに任せた」の違い
- AI 支援を使った
- AI が自動実行した
- AI が自動承認した
この三つは同じではありません。責任の所在も、信頼性の考え方も変わります。
まとめ
- AI 活用で重要なのは、速度ではなく、検証と責任の設計です。
- trustworthiness は、透明性、説明責任、人間監督を含む概念です。
- AI を使うほど、人がどこで責任を持つかを明確にする必要があります。
10. AI 利用開示と信頼低下リスクをゲーム理論で考える
AI を使ったことを伝える(開示する)のは、必ずしも常にプラスにはなりません。Stanford HAI の 2025 AI Index は、AI に対する期待と不安が併存していることを示しており、利用の拡大がある一方で、企業やシステムへの信頼が必ずしも高まっているわけではないと指摘しています。
Stanford HAI の AI Index 2025 や KPMG と University of Melbourne による 2025 年のグローバル調査でも、AI 利用の拡大と、信頼・ガバナンス上の懸念が並存していることが報告されています。
KPMG のグローバル要約では、世界的に AI への信頼はなお低く、AI システムを「信頼する」と回答した人は約 46%にとどまっていることが示されています。
さらに、AI 利用の開示が信頼を低下させる可能性も指摘されています。広告やニュース分野の研究では、AI 利用の開示がブランド評価やメディアに対する信頼を逆に損なう「backfire」が見られることが報告されています。
このように、AI 利用を明示することでかえって信頼を損なう事例が複数提示されているため、現時点では「透明性を出せば必ず信頼が上がる」とは言い切れないという見方が、多くの実証研究を踏まえた妥当な整理です。
10-1. シグナリングゲームとしての基本構造
この問題は、ゲーム理論ではシグナリングゲームとして理解できます。
- プレイヤー1: 提供者
- プレイヤー2: 顧客
- 提供者の選択: AI 利用を明示する / 明示しない
- 顧客の解釈: 誠実とみる / 低品質とみる / 価格を下げる理由とみる
もし顧客が「AI 使用 = 低コスト・低品質・手間をかけていない」というシグナルとして受け取れば、提供者が誠実さのために開示しても、価格評価や信頼評価が下がる可能性があります。
flowchart TD
A[提供者がAI利用を開示] --> B{顧客の解釈}
B --> C[誠実・透明だと評価]
B --> D[低品質・低努力だと評価]
C --> E[信頼維持または向上]
D --> F[信頼低下・価格評価低下]
10-2. なぜ「AIを使いました」が逆効果になるのか
顧客は、AI の存在そのものではなく、AI を使うことで何が省略されたのかを推測します。その結果、次のような解釈が起こりえます。
- 人の手間を減らしたのではないか
- 品質より効率を優先したのではないか
- 誤り確認が甘いのではないか
- ならば価格は下がるべきではないか
10-3. どう伝えるべきか
そのため、「AI を使った」こと単体を価値として前面に出さないほうがよい場面があります。代わりに、次のように伝えるほうが合理的です。
- AI 支援を活用して下書きや整理を高速化した
- ただし設計、検証、承認、責任は人が担っている
- テストとレビューを通過した成果物のみを提供している
- 高リスク領域は人が最終判断している
これは、透明性を保ちながら、負のシグナルを緩和する伝え方です。
まとめ
- AI 開示は、誠実さのシグナルにも、低品質のシグナルにもなりえます。
- 顧客の解釈次第で、信頼も価格評価も変わります。
- 「AI 使用」ではなく、「品質保証と責任体制」を中心に伝えるほうが、価値毀損を避けやすいです。
11. 小規模開発と大規模開発で何が違うのか
小規模開発では、一人が複数役割を兼任します。大規模開発では、役割を分けやすくなります。ただし、本質的な役割は大きく変わりません。変わるのは人数と境界の明確さです。
11-1. 小規模開発
- 一人が企画、設計、実装、テスト、運用を兼任しやすい
- そのぶん、視点の偏りが起きやすい
11-2. 大規模開発
- 役割を明示しやすい
- 連携や引き継ぎの設計が重要になる
11-3. 共通する本質
- 誰が何を決めるか
- 誰が何を作るか
- 誰が何を守るか
この三つは、規模に関係なく必要です。
まとめ
- 規模が違っても、責務の本質は大きく変わりません。
- 一人開発でも、頭の中では役割を分ける必要があります。
- チームが大きくなるほど、境界と連携の明確化が重要になります。
12. この章の到達目標
この章を終えた時点で、次の内容を説明できるようになることを目指します。
-
Webサービス設計で、なぜ役割分担が必要か
-
代表的な役割とその責務
-
AI が代替しやすい部分と、人が責任を持つ部分
-
AI 利用時の信頼性担保の考え方
-
AI 開示が信頼や価値認識へ与える影響 また、次の区別ができることも重要です。
-
企画と進行管理
-
デザインと実装
-
実装と品質保証
-
開発と運用
-
AI 支援と人間の最終責任
まとめ
- 役割名を覚えるだけでは不十分です。
- 責務、判断、責任、説明の違いで理解する必要があります。
- AI 時代ほど、役割分担は消えるのではなく再設計が必要になります。
13. 考えてみよう
- なぜ役割分担は「人を分けること」ではなく「責務を分けること」なのでしょうか。
- なぜ作る人と確かめる人の視点を分ける必要があるのでしょうか。
- なぜ公開後の役割まで設計時に意識する必要があるのでしょうか。
- なぜ一人開発でも役割分担の考え方が必要なのでしょうか。
- なぜ AI を使ったことの開示が、場合によっては価値低下を招きうるのでしょうか。
14. まとめ
- Webサービス設計における役割分担は、肩書きの一覧ではなく、責務の分離と連携の設計として理解するべきです。
- 企画、設計、実装、品質保証、運用、セキュリティは、それぞれ異なる視点と責任を持ちます。
- AI は、下書き、要約、分類、定型実装などを補助しやすい一方で、最終判断、承認、説明責任、リスク受容は人に残りやすいです。
- AI を使う場合は、人間レビュー、テスト、監査可能性、リスクに応じた人間監督を組み込むことが重要です。
- AI 利用の開示は、透明性のシグナルにもなりますが、顧客によっては低品質・低努力のシグナルとも解釈されうるため、品質保証と責任体制をセットで伝える必要があります。
15. 参考文献
- Web technology for developers - MDN
- Introduction to the server side - MDN
- Product Manager: Role & Best Practices for Beginners - Atlassian
- Product manager vs. project manager - Atlassian
- Agile Product Management - Atlassian
- Google’s Approach to Service Management: Site Reliability Engineering
- What is Site Reliability Engineering (SRE)? - Google SRE
- AI Risk Management Framework - NIST
- Artificial Intelligence Risk Management Framework (AI RMF 1.0) - NIST PDF
- AI Research - Trustworthy AI - NIST
- OECD AI Principles
- Recommendation of the Council on Artificial Intelligence - OECD
- The 2025 AI Index Report - Stanford HAI
- Trust, attitudes and use of artificial intelligence: A global study 2025 - University of Melbourne / KPMG PDF
- How Does AI Disclosure Shape Trust? - Journal of Advertising Research
- People want journalists to say when they use AI — but trust drops when they do - Ideastream