AquaDraft Ops Automation 要求分析書(ADO-RA-001)

文書管理情報

改訂履歴

1. はじめに

1.1 本書の目的

本書は、個人開発サービス「AquaDraft」の運用業務を対象に、現行業務(As-Is)を分析し、そこから導かれる課題と要求事項を体系的に整理することを目的とする。

本書で確定した要求事項は、要件定義書(ADO-RD-001)において機能要件・非機能要件へ展開される。本書は「何を求めるか」を定義するものであり、「どう実現するか」は取り扱わない。

1.2 適用範囲

AquaDraft本体、公式ブログ(blog.aqua-draft.com)、告知に用いる各SNS媒体、ソースコードリポジトリ、およびアクセス解析基盤を含む運用業務全般を対象とする。

1.3 対象読者

• プロジェクトオーナー(承認者)
• 本プロジェクトの実行担当(Claude)
• 連載記事の読者(本書は成果物として公開される)

1.4 用語定義

1.5 関連文書

2. プロジェクト概要

2.1 背景

AI技術の普及により、知識の整理・説明・定型作業の遂行はAIが高い水準で実施できるようになった。その結果、知識の保有を証明する手段(資格等)の相対的な価値は低下している。

一方で、AIに何ができて何ができないかを見極め、実際の業務へ組み込む判断は、知識の量では代替できない。この判断力を証明する手段は現時点で確立されていない。

本プロジェクトは、実在する個人開発サービスの運用業務を対象に、この判断を実践し、結果を記録することで、判断力そのものを実績として示すことを狙いとする。

2.2 目的

AquaDraftの運用業務に対し、AIの能力を正しく評価したうえで自動化を組み込み、人間の関与を可能な限り削減する。削減できた業務と、検証の結果として人間に残した業務の双方を、判断理由とともに記録する。

2.3 ゴール

最終ゴールは「作業負荷の軽減」ではなく「関与の不在に耐える」ことを指す。負荷軽減を目標に置いた場合、部分的な改善で目標が達成されたと判断され、検証が途中で止まるおそれがあるため、意図的に厳しい水準を設定する。

2.4 ステークホルダー

本プロジェクトに関与する人間はオーナー1名のみである。組織的な分業は存在せず、「人間の関与を削減する」対象は最初からオーナー自身に限定される。

3. 現行業務分析(As-Is)

3.1 対象業務領域

3.2 業務一覧

3.3 業務フロー(BIZ-01 素材追加)

現行は13工程で構成される。

13工程のうち9工程をオーナーが担っており、うち8工程が前半に集中している。Claudeへの委譲は、モデル引き渡し以降の機械的な工程に限られる。

3.4 告知業務の現状(BIZ-05、BIZ-06)

素材追加時に全媒体へ配信するという運用ルールは存在しない。投稿頻度、言語の出し分け、説明の粒度がいずれも媒体ごとに不統一である。

3.5 開発業務の現状(BIZ-02、BIZ-03)

アクセス解析上、利用者が存在しないわけではないが、声が到達する経路が存在しない。

3.6 発信業務の現状(BIZ-06)

3.7 保守・継続業務の現状(BIZ-16からBIZ-18)

初版の業務一覧には、運用を継続するために不可欠でありながら、現在いずれも実施されていない3業務が抜けていた。実施記録が無いために棚卸しの対象から落ちたものである。以下に工程まで分解する。

BIZ-16 依存パッケージの更新と脆弱性対応

BIZ-17 バックアップと復旧

BIZ-18 一般の問い合わせ対応

BIZ-11のユーザー投稿レイアウトの受付とは別である。BIZ-11は掲載応募の窓口であり、BIZ-18はそれ以外の一般の問い合わせを指す。

3.8 制約条件

なお、2026年5月から7月の3か月間は稼働時間を確保できたため集中的な開発が可能であり、6月のコード更新は131件に達した。しかし2026年8月の更新は0件であり、CON-01の影響は既に顕在化している。

4. 課題分析

4.1 課題一覧

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 要求一覧

5.3 要求と課題の対応(カバレッジ確認)

未対応の課題は存在しない。

版数1.0の時点では、この表がISS-012までで止まっていた。ISS-013からISS-019は2026-08-29のサイト実機確認で追加された課題であり、追加時に要求への展開とこの表の更新が行われていなかった。版数1.1で要求REQ-025からREQ-030を起こし、対応を確定させた。

6. To-Be方針

6.1 基本方針

AIの能力を業務単位で評価し、評価結果に応じた自動化の度合いを適用する。評価と適用の具体的な基準は要件定義書(ADO-RD-001)にて定義する。

自動化を試みた結果、効率またはリスクの観点から人間が担うべきと判断された業務については、人間へ戻す。これを失敗ではなく、実践と検証を経た正当な結論として扱い、判断理由を記録する。

6.2 人間に残す業務

以下の3業務は、検証を経ずとも人間に残すことを前提とする。

上記に加え、セキュリティに関わる変更は自動化の対象外とする。

6.3 発生時点で必ず報告する業務

以下の3業務は、自動化の度合いにかかわらず、事象が発生した時点でオーナーへ報告する。報告を省略しない。

これらは処理が正常に完了した場合も報告する。要件定義書6.2の「正常時は即時通知しない」方針に対する例外として固定する。オーナーが事実を知らないまま処理が進む状態を作らないことが目的であり、自動化の対象から外すという意味ではない。

6.4 段階的移行方針

一括での自動化は行わず、段階的に適用範囲を拡大する。各段階で効果を測定し、次段階の設計へ反映する。段階の区切りは企画書(ADO-PL-001)のPhase定義に従う。

7. スコープ

7.1 対象

• AquaDraftの運用業務(3.1に定める6領域)
• 運用業務を支える自動化の仕組みおよび記録・報告の仕組み
• 上記の設計・実装・運用を通じて得られた判断と知見の記録

7.2 対象外

8. 前提条件・制約条件

8.1 前提条件

8.2 制約条件

3.8に定めるCON-01からCON-06をそのまま制約条件として引き継ぐ。

9. 未決事項

以上