連載「AI時代にIT業界に求められるスキルや人材は何か」で進めている、AquaDraftの運用をAIで自動化するプロジェクトの成果物です。実際に作成した要求分析書(文書番号 ADO-RA-001)を、体裁を変えずそのまま公開しています。本文が「である調」なのは、社内で使う設計文書の様式に合わせているためです。
プロジェクトの経緯はAI時代にIT業界に求められるスキルや人材は何か -実践編 #1-をご覧ください。
この分析を受けて作成した要件定義書(ADO-RD-001)もあわせて公開しています。
全体スケジュールとタスク一覧はプロジェクト計画書(ADO-PP-001)にまとめてあります。
文書管理情報
| 項目 | 内容 |
|---|---|
| 文書番号 | ADO-RA-001 |
| 文書名 | AquaDraft Ops Automation 要求分析書 |
| 版数 | 1.0 |
| 作成日 | 2026-08-20 |
| 最終更新日 | 2026-08-20 |
| 作成者 | Claude(実行・分析担当) |
| 承認者 | プロジェクトオーナー(やまかず) |
| 承認状態 | 未承認 |
| 機密区分 | 公開(WordPress上で公開管理する。秘匿値・個人情報は記載しない) |
| 関連文書 | ADO-PL-001 企画書 / ADO-RD-001 要件定義書 |
改訂履歴
| 版数 | 日付 | 改訂者 | 改訂内容 |
|---|---|---|---|
| 1.0 | 2026-08-20 | Claude | 初版作成。企画書(ADO-PL-001)およびヒアリング結果を正式様式へ展開 |
1. はじめに
1.1 本書の目的
本書は、個人開発サービス「AquaDraft」の運用業務を対象に、現行業務(As-Is)を分析し、そこから導かれる課題と要求事項を体系的に整理することを目的とする。
本書で確定した要求事項は、要件定義書(ADO-RD-001)において機能要件・非機能要件へ展開される。本書は「何を求めるか」を定義するものであり、「どう実現するか」は取り扱わない。
1.2 適用範囲
AquaDraft本体、公式ブログ(blog.aqua-draft.com)、告知に用いる各SNS媒体、ソースコードリポジトリ、およびアクセス解析基盤を含む運用業務全般を対象とする。
1.3 対象読者
- プロジェクトオーナー(承認者)
- 本プロジェクトの実行担当(Claude)
- 連載記事の読者(本書は成果物として公開される)
1.4 用語定義
| 用語 | 定義 |
|---|---|
| AquaDraft | 本プロジェクトの対象となる水槽レイアウトシミュレーター。Webブラウザ上で動作する |
| オーナー | プロジェクトオーナー(やまかず)。本プロジェクトに関与する唯一の人間であり、最終承認者 |
| Claude | 実行・分析・自動化設計を担うAI。本プロジェクトの実務担当 |
| 素材 | AquaDraft上で配置できる水草・石・流木・底床などの3Dモデルおよびその情報 |
| 素材追加 | 新規素材を調査・選定・制作しAquaDraftへ組み込み、告知するまでの一連の業務 |
| As-Is | 現行の業務の姿。現状分析の対象 |
| To-Be | 実現後のあるべき業務の姿 |
| AI評価カテゴリ | AIに任せてよい度合いを示す判定区分。高信頼・中信頼・低信頼・自動化禁止の4段階 |
| 自動化分類 | 業務ごとの自動化の度合い。A(完全自動)からE(自動化しない)の5段階 |
| MoSCoW | 要求の優先度分類。Must(必須)、Should(推奨)、Could(可能なら)、Won’t(今回は対象外) |
| 回帰テスト | 変更によって既存の動作が壊れていないことを確認するテスト |
1.5 関連文書
| 文書番号 | 文書名 | 位置づけ |
|---|---|---|
| ADO-PL-001 | AquaDraft Ops Automation 企画書 | 本書の上位文書。プロジェクトの目的・体制・スケジュールを定義 |
| ADO-RD-001 | AquaDraft Ops Automation 要件定義書 | 本書の下位文書。本書の要求を要件へ展開 |
2. プロジェクト概要
2.1 背景
AI技術の普及により、知識の整理・説明・定型作業の遂行はAIが高い水準で実施できるようになった。その結果、知識の保有を証明する手段(資格等)の相対的な価値は低下している。
一方で、AIに何ができて何ができないかを見極め、実際の業務へ組み込む判断は、知識の量では代替できない。この判断力を証明する手段は現時点で確立されていない。
本プロジェクトは、実在する個人開発サービスの運用業務を対象に、この判断を実践し、結果を記録することで、判断力そのものを実績として示すことを狙いとする。
2.2 目的
AquaDraftの運用業務に対し、AIの能力を正しく評価したうえで自動化を組み込み、人間の関与を可能な限り削減する。削減できた業務と、検証の結果として人間に残した業務の双方を、判断理由とともに記録する。
2.3 ゴール
| 区分 | 内容 |
|---|---|
| 実践ゴール | Claudeの機能(タスク管理、サブエージェント、スキル、定期実行、監視等)を用いて運用業務の自動化を実現すること |
| 最終ゴール | オーナーが関与しなくてもAquaDraftの運営が停止しない状態にすること |
最終ゴールは「作業負荷の軽減」ではなく「関与の不在に耐える」ことを指す。負荷軽減を目標に置いた場合、部分的な改善で目標が達成されたと判断され、検証が途中で止まるおそれがあるため、意図的に厳しい水準を設定する。
2.4 ステークホルダー
| ステークホルダー | 役割 | 本プロジェクトにおける関心事 |
|---|---|---|
| オーナー | プロジェクトオーナー、最終承認者、現行業務の全担当者 | 夜間の限られた稼働時間で運営を継続できること。品質を落とさないこと |
| Claude | 実行・分析・自動化設計 | 委譲された業務を、追跡可能な形で確実に遂行すること |
| AquaDraft利用者 | サービス利用者 | 素材が継続的に追加されること。不具合が放置されないこと |
| 連載記事の読者 | 成果物の閲覧者 | 実践の過程と判断理由が、成功・失敗を問わず開示されること |
本プロジェクトに関与する人間はオーナー1名のみである。組織的な分業は存在せず、「人間の関与を削減する」対象は最初からオーナー自身に限定される。
3. 現行業務分析(As-Is)
3.1 対象業務領域
| 領域 | 含まれる業務 |
|---|---|
| 開発運用 | コード変更の記録、課題管理、リリース作業 |
| サービス運用 | アクセス監視、不具合検知、稼働状態の把握 |
| 発信運用 | リリース告知、SNS投稿、ブログ記事の作成 |
| 改善活動 | 改善案の抽出、優先順位付け |
| 素材制作 | 素材の調査・選定・制作・組み込み |
3.2 業務一覧
| 業務ID | 業務 | 現行の担当 | 実施頻度(現状) | 記録の有無 |
|---|---|---|---|---|
| BIZ-01 | 素材追加 | オーナー(9工程)、Claude(3工程) | 不定期(希望は週1回) | コミットログのみ |
| BIZ-02 | 不具合修正 | オーナー、Claude | 発見時のみ | コミットログのみ |
| BIZ-03 | UI改修・機能追加 | オーナー、Claude | 2026年7月末で一段落 | コミットログのみ |
| BIZ-04 | 課題・改善案の管理 | オーナー | 不定期 | 記録なし(リポジトリの課題管理機能は未使用) |
| BIZ-05 | 告知(SNS 3媒体) | オーナー | 不定期・媒体ごとにばらつき | 記録なし |
| BIZ-06 | ブログ記事作成(4種類) | オーナー、Claude | 不定期 | 記事そのもの |
| BIZ-07 | アクセス解析の確認 | オーナー | 不定期 | 記録なし |
| BIZ-08 | 本番反映 | オーナー | 都度 | コミット履歴 |
| BIZ-09 | 運用状態の把握 | 実施していない | なし | なし |
3.3 業務フロー(BIZ-01 素材追加)
現行は13工程で構成される。
| 工程No | 工程 | 担当 | 種別 | 備考 |
|---|---|---|---|---|
| 1 | 人気素材の調査 | オーナー | 判断 | 情報源は記事検索、動画、SNS投稿、レイアウト作例、水草通販サイト |
| 2 | 現状の素材の確認 | オーナー | 確認 | AquaDraft上の既存素材と突き合わせ |
| 3 | 追加対象の選定(1回あたり1件から3件) | オーナー | 判断 | 優先度は人気素材の網羅、次にタイプ違い、その後ニッチ |
| 4 | 参考画像の収集 | オーナー | 作業 | |
| 5 | AIによる画像生成の試行 | オーナー | 作業 | 著作権の観点から、収集画像をそのまま用いない方針による |
| 6 | 生成物のクオリティ判定 | オーナー | 判断(承認) | 判定基準は実物イメージからの乖離 |
| 7 | 3Dモデル化 | オーナー | 作業 | 外部サービスを利用 |
| 8 | モデルの引き渡し | オーナー | 作業 | |
| 9 | モデルの圧縮 | Claude | 作業 | |
| 10 | AquaDraftへの実装 | Claude | 作業 | |
| 11 | 動作確認 | Claude | 作業 | |
| 12 | 本番反映 | オーナー | 承認 | |
| 13 | 告知 | オーナー | 作業 |
13工程のうち9工程をオーナーが担っており、うち8工程が前半に集中している。Claudeへの委譲は、モデル引き渡し以降の機械的な工程に限られる。
3.4 告知業務の現状(BIZ-05、BIZ-06)
| 媒体 | 名義 | 言語 | 投稿形式 | 実施状況 |
|---|---|---|---|---|
| X | 他チャンネルとの共用アカウント | 日本語 | 短文、ハッシュタグ、画面キャプチャ1枚 | 直近2件。表示数は47から61、固定投稿のみ763 |
| AquaDraft専用ページ | 日本語・英語を別投稿 | カテゴリ別に整理した更新内容、動画または複数画像 | 日英2本ずつを2回 | |
| 個人名義 | 日英混在 | タイトルと説明文。粒度が投稿ごとに不統一 | ピン4件で停止 | |
| 公式ブログ | AquaDraft公式 | 日本語(英語版サイトあり) | 告知記事、レイアウト作例、素材解説 | 直近の告知は2026-07-06 |
素材追加時に全媒体へ配信するという運用ルールは存在しない。投稿頻度、言語の出し分け、説明の粒度がいずれも媒体ごとに不統一である。
3.5 開発業務の現状(BIZ-02、BIZ-03)
| 観点 | 現状 |
|---|---|
| 不具合の検知経路 | オーナーの目視のみ。大半は他作業の動作確認時に副次的に発見 |
| 利用者からの報告経路 | 存在しない |
| 自動テスト | 未導入。テストファイル0件、テストフレームワーク未導入 |
| CI/CD | デプロイ用の自動化のみ |
| 自動化された品質担保 | 型チェックと静的解析まで |
| 機能・UIの進捗 | 2026年7月末で必要な機能とUIが出揃い、現在は素材追加フェーズ |
| 継続課題 | 操作の軽快さと素材のリアリティのトレードオフ最適化。判定はオーナーの体感に依存 |
アクセス解析上、利用者が存在しないわけではないが、声が到達する経路が存在しない。
3.6 発信業務の現状(BIZ-06)
| 種類 | 目的 | 現状 |
|---|---|---|
| リリース告知 | アップデートの周知 | 更新のたびに作成 |
| 素材辞典 | 検索経由のリーチ向上 | 初期にまとめて作成済み。今後は素材追加に合わせて1素材1本の方針 |
| レイアウト作例 | 実現できることの提示、権威性とファンの醸成 | 公開済み。保存データを配布し、読み込めば同じ状態から作業を開始できる |
| ノウハウ | アクアリウム全般の知識提供、アフィリエイト収益 | 未着手 |
3.7 制約条件
| 制約ID | 制約 | 内容 |
|---|---|---|
| CON-01 | 稼働時間 | 2026年8月より平日日中は就業のため作業不可。稼働は夜間から深夜のみ |
| CON-02 | AI利用枠 | 素材追加1回あたりAI利用枠を3時間から4時間分消費。上限到達時は最大5時間の待機が発生 |
| CON-03 | 外部データ取得 | 動画サイトおよびSNS投稿の自動取得は不可。情報源として当てにできない |
| CON-04 | 商品情報の取得 | 商品ページからの画像・価格の自動取得は行わない。リンクのみで構成する |
| CON-05 | 本番反映 | 本番反映はオーナーが手動で実施する既存ルールがある |
| CON-06 | 実施体制 | 人的リソースはオーナー1名のみ。増員の予定はない |
なお、2026年5月から7月の3か月間は稼働時間を確保できたため集中的な開発が可能であり、6月のコード更新は131件に達した。しかし2026年8月の更新は0件であり、CON-01の影響は既に顕在化している。
4. 課題分析
4.1 課題一覧
| 課題ID | 課題 | 発生元業務 | 影響度 | 根拠 |
|---|---|---|---|---|
| ISS-001 | 素材追加13工程のうち9工程がオーナーに集中し、稼働制約下でスループットが確保できない | BIZ-01 | 高 | 3.3、CON-01、CON-02 |
| ISS-002 | 不具合の検知経路がオーナーの目視のみであり、オーナーが手を止めると検知が停止する | BIZ-02 | 高 | 3.5 |
| ISS-003 | 自動テストが未整備であり、人手による確認を外すと品質を担保できない | BIZ-02、BIZ-03 | 高 | 3.5 |
| ISS-004 | 利用者からの不具合・要望の受付経路が存在しない | BIZ-02、BIZ-04 | 中 | 3.5 |
| ISS-005 | 素材情報が構造化されておらず、告知文・辞典記事を都度手作業で書き起こしている | BIZ-05、BIZ-06 | 高 | 3.4、3.6 |
| ISS-006 | 告知が定常運用になっておらず、媒体ごとに頻度・言語・粒度が不統一である | BIZ-05 | 中 | 3.4 |
| ISS-007 | 課題および意思決定の経緯が追跡できない(記録がコミットメッセージのみ) | BIZ-04 | 中 | 3.2 |
| ISS-008 | アクセス解析の定期確認フローがなく、異常の発生に気づけない | BIZ-07 | 中 | 3.2 |
| ISS-009 | 運用状態を俯瞰する定期レポートが存在しない | BIZ-09 | 中 | 3.2 |
| ISS-010 | 操作の軽快さと素材のリアリティのトレードオフ判定が体感に依存し、数値化されていない | BIZ-03 | 中 | 3.5 |
| ISS-011 | 改善案の抽出元が確立されていない | BIZ-04 | 低 | 3.2 |
| ISS-012 | SNSアカウントの名義が媒体ごとに分散している | BIZ-05 | 低 | 3.4 |
4.2 課題の構造
課題は以下の3系統に整理できる。
系統1: 人間への集中(ISS-001、ISS-005、ISS-006)
素材追加の前半工程と告知業務がオーナーに集中している。この2つは本来つながっており、素材情報が構造化されていないこと(ISS-005)が、告知を手作業に固定している。素材情報を構造化データとして保持できれば、告知4媒体への配信と素材辞典記事の生成は同一の材料から派生できる。すなわち発信業務の自動化とは、投稿文を生成する仕組みではなく、素材情報を構造化して保持する仕組みの構築である。
系統2: 検知の欠落(ISS-002、ISS-003、ISS-004、ISS-008、ISS-009)
異常を検知する経路が、いずれもオーナーの目視に依存している。最終ゴール(オーナーの関与なしに運営が停止しない状態)に対して、本系統は直接的な阻害要因である。人間による確認を外す以上、変更箇所を中心とした確認では不足し、操作の流れを通しで検証する回帰テストが必須となる。
系統3: 記録・可視化の欠落(ISS-007、ISS-010、ISS-011)
判断の根拠と経緯が記録されていない。本プロジェクトは判断そのものを成果物とするため、記録の欠落は成果の欠落に直結する。
5. 要求事項
5.1 要求の分類
| 分類 | 定義 |
|---|---|
| 業務要求 | 業務の進め方に関する要求 |
| 機能要求 | 実現すべき機能に関する要求 |
| 品質要求 | 品質・安全性・セキュリティに関する要求 |
| 運用要求 | 運用体制・報告に関する要求 |
優先度はMoSCoW法により、Must(必須)、Should(推奨)、Could(可能なら)、Won’t(今回は対象外)の4段階で付与する。
5.2 要求一覧
| 要求ID | 分類 | 要求事項 | 優先度 | 対応課題 |
|---|---|---|---|---|
| REQ-001 | 業務要求 | 素材追加業務の前半工程(調査・選定・素材準備)を自動化し、オーナーの関与をクオリティ判定と本番反映の承認に限定できること | Must | ISS-001 |
| REQ-002 | 機能要求 | 素材情報(名称、カテゴリ、特徴、追加日等)を構造化データとして一元管理できること | Must | ISS-005 |
| REQ-003 | 機能要求 | 構造化された素材情報から、各媒体向けの告知文および素材辞典記事の下書きを生成できること | Must | ISS-005、ISS-006 |
| REQ-004 | 業務要求 | 素材追加を契機として、告知が全対象媒体へ定常的に実施されること | Should | ISS-006 |
| REQ-005 | 品質要求 | 操作の一連の流れを最初から最後まで再現する回帰テストを整備し、自動実行できること | Must | ISS-003 |
| REQ-006 | 機能要求 | 不具合を人手の目視によらず検知できること | Must | ISS-002 |
| REQ-007 | 機能要求 | 利用者からの不具合報告・要望を受け付ける経路を設けること | Should | ISS-004、ISS-011 |
| REQ-008 | 機能要求 | アクセス解析および検索パフォーマンスのデータを定期取得し、異常値・急変を検知できること | Must | ISS-008 |
| REQ-009 | 機能要求 | 開発ログから課題および改善案の下書きを生成し、追跡可能な形で記録できること | Should | ISS-007、ISS-011 |
| REQ-010 | 機能要求 | 週次の運用レポートを自動生成できること | Must | ISS-009 |
| REQ-011 | 運用要求 | 自動処理の結果がオーナーに届くこと。異常時は即時に報告し、正常時は週次レポートに集約すること | Must | ISS-009 |
| REQ-012 | 機能要求 | 描画性能を数値で測定し、素材追加のたびに影響を自動計測して、閾値超過時に報告できること | Should | ISS-010 |
| REQ-013 | 機能要求 | リリースノートおよびブログ記事の下書きを自動生成できること | Should | ISS-005 |
| REQ-014 | 業務要求 | すべてのタスクについて、着手前にAI評価カテゴリを判定し、判定結果を記録できること | Must | 2.2 |
| REQ-015 | 品質要求 | すべての自動処理について、実行ログを後から追跡できること | Must | ISS-007 |
| REQ-016 | 業務要求 | AI評価カテゴリおよび自動化分類の判定を、運用実績に基づいて見直せること。人間の関与を増やす方向への見直しを正当な結論として扱うこと | Must | 2.2 |
| REQ-017 | 品質要求 | 素材のクオリティ判定はオーナーの承認を必須とすること | Must | 3.3 |
| REQ-018 | 品質要求 | 本番反映(コード・記事とも)を自動化しないこと。常にオーナーが最終確認すること | Must | CON-05 |
| REQ-019 | 品質要求 | セキュリティに関わる変更を自動化しないこと。常に人間が担うこと | Must | 2.2 |
| REQ-020 | 品質要求 | 秘匿情報(APIキー、パスワード等)をAIに送らず、ログにも出力しないこと | Must | 2.2 |
| REQ-021 | 運用要求 | 成果物をWordPress上で管理すること。個人アカウント配下のクラウドストレージを使用しないこと | Must | 2.2 |
| REQ-022 | 運用要求 | 素材追加1回の処理が、AI利用枠の1日分に収まるよう設計すること | Should | CON-02 |
| REQ-023 | 運用要求 | 自動処理が失敗した場合の代替手段(フォールバック)を定義すること | Should | ISS-002 |
| REQ-024 | 業務要求 | SNSアカウントの名義および運用方針を整理すること | Could | ISS-012 |
5.3 要求と課題の対応(カバレッジ確認)
| 課題ID | 対応する要求ID | 充足状況 |
|---|---|---|
| ISS-001 | REQ-001 | 充足 |
| ISS-002 | REQ-006、REQ-023 | 充足 |
| ISS-003 | REQ-005 | 充足 |
| ISS-004 | REQ-007 | 充足 |
| ISS-005 | REQ-002、REQ-003、REQ-013 | 充足 |
| ISS-006 | REQ-003、REQ-004 | 充足 |
| ISS-007 | REQ-009、REQ-015 | 充足 |
| ISS-008 | REQ-008 | 充足 |
| ISS-009 | REQ-010、REQ-011 | 充足 |
| ISS-010 | REQ-012 | 充足 |
| ISS-011 | REQ-007、REQ-009 | 充足 |
| ISS-012 | REQ-024 | 充足(優先度Could) |
未対応の課題は存在しない。
6. To-Be方針
6.1 基本方針
AIの能力を業務単位で評価し、評価結果に応じた自動化の度合いを適用する。評価と適用の具体的な基準は要件定義書(ADO-RD-001)にて定義する。
自動化を試みた結果、効率またはリスクの観点から人間が担うべきと判断された業務については、人間へ戻す。これを失敗ではなく、実践と検証を経た正当な結論として扱い、判断理由を記録する。
6.2 人間に残す業務
以下の3業務は、検証を経ずとも人間に残すことを前提とする。
| 業務 | 理由 |
|---|---|
| 素材のクオリティ判定 | シミュレーターとしての価値の根幹に関わる。実物イメージからの乖離判定は、正解の基準自体が定量化できていない |
| レイアウト作例の制作 | 創作行為であり、権威性とファンの醸成という目的上、制作者の意図が価値の源泉である |
| 本番反映の承認 | 失敗時に取り返しがつかない。既存ルールであり変更しない |
上記に加え、セキュリティに関わる変更は自動化の対象外とする。
6.3 段階的移行方針
一括での自動化は行わず、段階的に適用範囲を拡大する。各段階で効果を測定し、次段階の設計へ反映する。段階の区切りは企画書(ADO-PL-001)のPhase定義に従う。
7. スコープ
7.1 対象
- AquaDraftの運用業務(3.1に定める5領域)
- 運用業務を支える自動化の仕組みおよび記録・報告の仕組み
- 上記の設計・実装・運用を通じて得られた判断と知見の記録
7.2 対象外
| 項目 | 対象外とする理由 |
|---|---|
| AquaDraft本体の新規機能開発 | 本プロジェクトの目的は運用業務の自動化であり、製品開発ではない。必要な機能は2026年7月末で出揃っている |
| 収益化施策の立案・実施 | 本プロジェクトの評価軸は自動化の達成度であり、収益ではない |
| AquaDraftのインフラ移行・技術スタックの刷新 | 現行構成で目的を達成できる |
| 他サービスへの横展開 | 本プロジェクトの検証完了後に別途判断する |
8. 前提条件・制約条件
8.1 前提条件
| 前提ID | 前提条件 |
|---|---|
| PRE-01 | オーナーは夜間から深夜の時間帯に稼働できる |
| PRE-02 | Claudeは継続して利用可能であり、利用枠の範囲内で稼働する |
| PRE-03 | AquaDraftの現行機能は安定して稼働しており、大規模な改修を要しない |
| PRE-04 | アクセス解析基盤は導入済みであり、データ取得が可能である |
| PRE-05 | 記事投稿基盤は稼働済みであり、既存の投稿経路を利用できる |
8.2 制約条件
3.7に定めるCON-01からCON-06をそのまま制約条件として引き継ぐ。
9. 未決事項
| 番号 | 未決事項 | 決定期限 | 決定者 |
|---|---|---|---|
| OPEN-01 | 最初に着手する対象業務。週次運用レポートの自動生成を先行させるか、素材追加業務の自動化を先行させるか | 要件定義書の承認まで | オーナー |
| OPEN-02 | 利用者からの報告受付経路の方式(フォーム、リポジトリの課題管理機能、SNSのいずれか) | 該当機能の設計着手まで | オーナー |
| OPEN-03 | 描画性能の測定指標および閾値の定義 | 該当機能の設計着手まで | Claudeが案を作成しオーナーが承認 |
| OPEN-04 | SNSアカウント名義の整理方針(REQ-024) | 未定(優先度Could) | オーナー |
以上