AIに業務ツールを作ってもらう前に決めること｜非エンジニア向け要件整理

AIに業務ツールを作ってもらいたい。
でも、何を伝えればいいのか分からない。
画面や機能を思いつくたびに追加していたら、最初に困っていた仕事から話が離れてしまう。

そんなときは、コードを頼む前に、仕事の流れを書き出してみてください。

まず決めたいのは、誰の、どの作業を、どう変えたいのか。
そして、どんな状態なら仕事で使えると判断するのかです。

専門的な設計図がなくても、入力する情報、欲しい結果、失敗したときの扱いを日本語でそろえるところから始められます。

私が保守管理プラグインを作ったときは、まず現場の課題と欲しい機能を言葉にしました。

ここからは、あなたの仕事をAIへの指示書に変えるために、作る前に決めたいことを一緒に見ていきましょう。

AIに業務ツールを作ってもらう前に決める7項目

要件整理は、仕事で必要なことを、作る人と確認する人が同じ意味で読める形にする作業です。最初は、次の表の問いに自分の言葉で答えるところから始めてみてください。

1．目的は「便利にする」より、困っている作業を書く

まず、今の仕事のどこで困っているかを書いてみましょう。

たとえば「依頼を管理したい」だけでは、依頼の受付、担当者への割り振り、期限管理のどこから手を付けるかが曖昧です。

「メールとチャットに依頼が分かれ、未対応のものを探しにくい」と書けば、まず必要なのは一覧と対応状況の確認だと考えやすくなります。

今は誰が、何を見ながら、どこで迷っているのかも添えてみてください。

作業時間を減らしたいなら、現在の時間を記録しておき、試作品を使った後に比べましょう。
効果の数値を出すのは、その確認が済んでからです。

2．見る人、更新する人、承認する人を分ける

同じツールを使っていても、全員が同じ操作をするとは限りません。

担当者は対応状況を更新する。
責任者は完了を承認する。
依頼者は自分の依頼だけを見る。

こうして、誰がどの操作をするのかを先に分けておきましょう。

画面にボタンが見えないことと、データを変更できないことは、別々に確認してください。

WordPressのプラグインなら、更新を受け付ける処理で利用者の権限を確認する必要があります。

詳しい方法はWordPress公式の権限チェック解説で確認できます。

要件メモには「閲覧だけの人は更新・削除できない」と書き、実装後にその動きを確かめましょう。

3．入力データは、架空の見本からそろえる

AIに見本を渡すときは、実際の顧客名や問い合わせ内容を使わず、架空のデータを用意してください。

依頼日、依頼内容、担当者、対応状況など、必要な項目の名前と意味がそろえば、画面や一覧の相談を始められます。

入力方法も決めておきましょう。

手で入力するのか、CSVを読み込むのか、別のサービスと連携するのかで、確かめることが変わります。

必須項目、空欄にしてよい項目、日付の形式、重複の見分け方までメモしておくと、そのまま後のテストにも使えます。

既存の業務情報を外部AIへ送ってよいかは、利用中のサービスの条件と、所属する組織のルールで確認してください。

ツール内に保存するデータも、対象、保存先、保管期間、削除できる人まで決めておきましょう。

試作で扱う情報と本番で扱う情報を分けておくと、次に何を確認するかがはっきりします。

4．欲しい結果は、見る場面まで具体化する

「ダッシュボードが欲しい」だけでは、見た目が整っても、仕事に必要な情報が足りないことがあります。

「朝の確認で未対応の依頼だけを一覧にし、担当者と期限を見たい」のように、使う場面まで書いてみてください。

結果を画面で見るだけなのか、CSVとして保存するのか、誰かへ送るのかも分けましょう。

確認用の一覧を作りたい段階で、外部への自動通知まで一緒に作る必要があるか、いったん考えてみてください。

通知を入れるなら、送る条件、宛先、内容、人の承認が必要な場面も決めておきます。

5．うまくいかない場合の動きを決める

情報が足りない、同じ依頼が二度届く、期限が過ぎる、保存に失敗する。

うまく進む場合だけでなく、こうした例外が起きたときの動きも一緒に考えておきましょう。

「必須項目が空なら保存せず、どの項目が必要か知らせる」
「重複の可能性があれば、人が確認するまで登録を止める」

ここまで書けば、期待する動きがはっきりします。

AIに判断を任せる処理でも、判断できないときは人へ戻す条件を用意してください。

失敗を見えなくしたり、不足情報を推測で埋めたりしないかを、実装後に確かめましょう。

6．最初の試作品に必要な範囲を決める

最初の版は、今困っている作業を確かめられる範囲から始めましょう。

依頼管理なら、まずは登録、一覧表示、対応状況の更新まで。
請求、契約上の回数計算、外部通知を後の検討に回せば、先に何を試すかが明確になります。

まず必要な動きを試し、使う人の反応を見てから機能を広げていけば、何のために追加するのかを確かめながら進められます。

「今回作る」
「後で検討する」
「触らない既存データや設定」
の三つを書いておくと、追加依頼が出たときにも元の目的へ戻れます。

7．完成条件と、使い続ける人を決める

「画面が開く」だけを完成条件にすると、仕事で使えるかどうかの確認が残ります。

登録した情報が一覧と一致する。
更新後に開き直しても状態が残る。
権限のない人は変更できない。

こうした動きを、使う人が確認できる言葉で書いておきましょう。

運用については、確認担当、バックアップ、元へ戻す手順、不具合の記録方法を決めておきます。

外部サービスを使うなら、利用料の上限と、それを確認する担当も忘れずに決めましょう。

更新や障害のときに誰が判断するかまで分かれば、試作から本番へ進めるかを考えやすくなります。

保守管理プラグインで考える、作る前の判断

保守管理プラグインの開発実録では、契約状況や修正履歴をWordPressの管理画面で確認する仕組みを紹介しています。

その記事では、修正依頼をチャットやメールで受け、双方で作業内容に合意してから着手する運用も説明しています。

このプラグインを要件として書き直すなら、画面で確認する情報と、人が判断することを分けると考えやすくなります。

そこで、次のように整理してみました。

開発時の指示書をそのまま載せたものではありません。
ご自身の業務に応用するときの、要件の書き方として見てください。

業務に取り入れるときも、画面をそのまままねる前に、何を見たいのか、何を人が決めるのかを書いてみてください。

完成画面や開発の流れは、リンク先の実録で詳しく紹介しています。
それも参考にしながら、下のテンプレートにはご自身の業務の条件を入れてみましょう。

サイトの制作・作り替えで要件を整理する場合は、StudioとWordPressの比較も参考になります。独自機能、更新する人、費用、移行条件を同じ観点で比べられます。

そのまま記入できる、AIへの要件整理テンプレート

次のテンプレートをコピーし、分かるところから埋めてみてください。

未定の項目は「未定」のままで大丈夫です。
AIに空欄を推測で埋めさせず、判断が必要な点を質問にしてもらいましょう。

全部を書き切れなくても、作り始める前に分からない点が見つかれば、次に聞くことがはっきりします。

使う人に聞くことと、実装担当へ確認することを分けて、次の相談につなげてください。

記入例：架空の修正依頼管理表で考える

ここでは、説明用に架空の修正依頼管理表を用意しました。

実在の顧客からの依頼や、稼働中のツールの仕様を示す例ではありません。
要件の書き方を考えるための見本として読んでください。

このように書けば、「依頼管理ツールを作って」という依頼に、入力、操作、確認方法が加わります。

AIから案が返ってきたら、何を満たしていて、何が足りないかを、このメモと照らし合わせてみてください。

契約条件や回数の扱いは、ご自身の業務で確認してください。

私のプラグインと同じ機能を取り入れる場合も、誰が承認し、何を記録するのかを決めてから、作る範囲へ加えましょう。

AIには、不足している判断を先に質問してもらう

実装を頼む前に、テンプレートの中で食い違いそうな点を確認してみましょう。
次の依頼文を添えると、要件を見直すための返答を求められます。

この依頼文を添えても、AIの返答が正しいとは限りません。

提案された内容を、実際に使う人と確認してください。

「その項目は入力できない」、「その操作をするのは別の担当者」と分かったら、要件メモへ戻して直しましょう。

どのAIを使うか選ぶ前に、どんな結果が必要なのかを決めておくと、次の選択もしやすくなります。

指示の出し方は、プロンプトエンジニアリングの基礎と型でも説明しています。
伝え方に迷ったときは、あわせて読んでみてください。

「動いた」で終わらせず、受入テストで確かめる

受入テストは、欲しかった動きになっているかを、使う側が確かめる作業です。専門用語で書く必要はありません。

「この操作をしたら、この結果になる」という組合せを並べてみましょう。

最初は、正常に使う場合と、困りそうな場合の両方を試しましょう。

期待どおりにならなければ、使った架空データ、操作、期待した結果、実際の結果を記録してください。

「何か変」と伝えるより、修正する側が状況を再現しやすくなります。

本番のデータを入れる前に、確認結果を残し、バックアップから戻せるかも確かめてください。

外部サービスへの送信、権限変更、削除など、影響が大きい操作は、責任を持つ担当者や実装を確認できる人と一緒に試しましょう。

既存サービスの画面を操作する自動化を頼む場合は、APIのない業務画面をAIで自動化する前の確認事項も参考になります。対象画面、任せる操作、照合と失敗時の扱いを具体的にできます。

要件整理で迷いやすいこと

プログラミングを知らなくても書けますか？

目的、使う人、入力する項目、欲しい結果は、業務を知っている人が書ける部分です。

技術的な実現方法は、実装を担当する人やAIに案を出してもらいましょう。

ただし、その案の安全性や運用への適合を、コードを読めないまま保証できるわけではありません。

判断しきれない点は、確認担当へ戻してください。

要件定義書は長くないといけませんか？

小さな試作なら、まず一枚のメモから始めてみてください。長さより、使う人と作る人が同じ操作と結果を想像できるかを確かめましょう。

入力項目、例外、確認条件が増えたら、別の表に分けて追記すれば大丈夫です。

AIが提案した機能は、全部入れた方がよいですか？

元の困りごとを解決するために必要かどうか、一つずつ確認してみましょう。

便利そうな機能でも、初回の確認に必要なければ、後の候補に残しておけます。

外部連携や自動通知を加えるときは、費用、権限、送信先、失敗時の対応も一緒に見直してください。

まずは、今の仕事で困っている一場面を書き出す

AIへの要件整理は、立派な仕様書を書くところから始めなくて大丈夫です。

まず、今の仕事で困っている一場面を書き、誰が何を入力して、どんな結果を見たいかを添えてみてください。

空欄が残っていても大丈夫です。
分からない点を質問に変え、使う人が判断できる形にしておきましょう。

完成画面のイメージに加えて、例外と確認条件がそろえば、AIの提案を仕事の条件に照らして判断できます。

自分の業務で何を整理すればよいか相談したい場合は、お問い合わせフォームから、目的と困っている場面をお知らせください。

実際の顧客情報や認証情報は含めず、説明できる範囲からで十分です。

LON | AI Work Hacker

非エンジニア実装家 / AI業務委託

XYouTubeContact

「コードは書かない。AIを操る。」

普段は業務委託のプロとして、AI企業のLINE運用や自動化システム構築を担当。

エンジニア経験ゼロから、AIだけを武器にツールを自作する「実務ハック」を研究中。