生成AIによる業務改善の思考プロセス。課題を構造化してツールへ落とし込む
こんにちは。組織開発室に所属し、組織開発を担当しているてぃーびーです。
AIツールを開発する際、重要なのはどのモデルを使うか、どう実装するか、ということではありません。目の前の業務課題を、AIが解ける形に構造化する思考プロセスそのものです。
この記事では、AIツール開発の全体フローと、具体的な事例を通じた思考の整理法を解説します。
1. AIツール開発のプロセス
ツールを形にするまでのステップを分解します。
1-1. 着想
AIツール開発は、業務の課題を発見することから始まります。「なぜかいつも時間がかかる」「この作業は誰がやっても同じではないか？」という違和感を起点に、AIという手段をどう適用させるかを検討します。AIの特性を理解しておくことで、その課題にAIが適しているかどうか判断しやすくなります。
1-1-1. 着想の前提
AIツールを企画する際、まずはAIが得意なこと・苦手なことを把握し、活用範囲を正しく理解しておく必要があります。
生成AIが最も得意とするのは、パターン認識に基づく情報の生成と変換です。これは、膨大な学習データから統計的なパターンを読み取り、出力を生成しているためです。質問に対する答えに一定のパターンや傾向があり、過去の経験から結果が予想できそうな領域は、AIの活用に非常に適しています。
一方で、100%の正確性や唯一の正解が求められる領域には不向きです。こういった業務には適用しないか、素案やたたき台の作成まで任せて、そのあとは人間に任せるなどの使い分けが必要です。
1-1-2. 着想の種類
AI活用の着想には、大きく分けて2つのアプローチがあります。
- 課題から着想 : 解決したい具体的な現場の課題があり、その解決策としてAIを適用するケースです。
- 手段から着想 : AIでこんなことができるようになったという技術的な進化から、それを既存の業務に適用できないか検討するケースです。
1-2. 課題の整理
着想したアイデアを解くべき問いへ昇華させるステップです。単にAIで楽にするではなく、業務の本質を捉えるために以下の2点を言語化します。
1-2-1. 業務の目的を再定義する
その業務は何のために存在し、誰にどんな価値を届けるものかを明確にします。
- 誰のために？ : 顧客、上司、チームメンバー、自分自身など。
- 何を達成すれば成功か？ : 納期の短縮、精度の向上、新しい付加価値の創出など。
1-2-2. 理想と現状のギャップを特定する
理想の状態と現在の状態を比較し、その間にあるギャップを可視化します。このギャップを埋めることこそが、AIツールの役割となります。
| ギャップの分類 | 具体的な内容 |
|---|---|
| 実務の壁 | 時間にかかる : 手順が多く、単純作業にリソースが削られている状態。 |
| 品質の壁 | バラつきがある : スキルや経験によってアウトプットの質が不安定な状態。 |
| 心理の壁 | 重荷に感じる : 難易度が高かったり、正解がわからず着手まで時間がかかる状態。 |
1-2-3. 業務プロセスの整理
業務が単発で完結せず、複数のプロセスや主体を横断している場合、そのプロセスを整理します。
1-3. インパクト予想
導入によって得られる価値を見積もります。
- 定量的価値 : 削減される工数（時間 × 人数 × 単価）。
- 定性的価値 : 心理的ハードルの低下、アウトプットの標準化、意思決定の迅速化。
投資対効果と導入コストを天秤にかけ、実装の優先順位を判断します。
1-4. 構造整理
業務をAIへの指示書へ翻訳するための前提となるステップです。まずは、ツールにする前の段階の既存の業務をベースに、この業務はどのようなものかを整理します。
- インプット : どのようなデータが必要か？
- プロセス : どのような思考手順で処理するか？
- アウトプット : 最終的な形式やトーンはどうあるべきか？
1-5. 実装
1-4で整理した要素を、AIが処理可能な形式（具体的なプロンプトや外部資料）に翻訳し、実装します。
| カテゴリ | 項目 | 内容の概要 |
|---|---|---|
| インプット | ソース情報 | めったに変化しない基本情報 |
| ユーザー入力 | 入力の都度変化する情報 | |
| プロセス | 制御用のプロンプト | Gemini (Gems) など基本的な動きを定めたプロンプト |
| アウトプット | 出力フォーマット | 出力する項目やレイアウトなど |
1-6. テスト
実際の業務データを用いて精度を検証します。ツールのユースケースを整理し、各ユースケースごとに利用目的が達成された状態を定めます。期待通りの回答が得られない場合、 1-4 の構造整理に戻って情報の過不足を確認します。
1-7. 運用設計
AIツールを構成するソース情報や入力内容が時間とともに変化がする場合や業務の流れが複数にまたがる場合、運用の設計が必要です。たとえば、ソース情報を一定期間ごとに更新する必要がある場合、更新プロセスを運用に組み込む必要があります。
1-8. リファレンス作成
ツールが正しく活用され、継続的に改善されるための情報をまとめます。
1-8-1. 利用者向けリファレンス
利用者が迷わず、意図通りの結果を引き出すためのガイドです。
- 入力ガイドライン : どのような情報を、どの程度の具体性で入力すべきかの解説。
- 入出力サンプル : 良い入力例と期待される出力結果の具体像を示すことで、活用のイメージを促す。
- 利用手順 : ツールの利用手順を説明。
- 活用のコツと注意点 : 望ましい回答を得るための工夫と、AIが苦手なケースの明記。
1-8-2. 運用関係者向けリファレンス
開発者や管理者がメンテナンスを行うための技術ドキュメントです。
- プロンプトの詳細 : 具体的な指示内容とその背景にある設計意図、採用したロジック。
- メンテナンス手順 : ソース情報の更新方法や、モデル変更時の再テスト手順。
1-9. 受け入れテスト
実際にツールを利用する関係者にテスト実施の協力を依頼します。 主要な利用ケースについて、リファレンスを添えて実施してもらい、フィードバックを得ます。必要に応じてフィードバックを踏まえてツールを改善し、改善の影響があればリファレンスを最新化します。
1-10. アーキテクチャ資料の作成
AIツールのノウハウの共有のための資料を作成します。作成した資料は社内全体に共有します。また、この内容をベースに社外登壇資料に発展することもあるでしょう。
2. 実践例：目標設定支援ツールの作成
2025年10月のイベントで登壇した際の、目標設定支援ツールの例について、この流れを例示します。
2-1. 着想
課題から着想したケースです。クラスメソッドでは、人事評価制度を改定するまでは非常に軽量な評価および目標設定のプロセスを採用していました。2022年10月に、一般的な企業でよくある目標設定・等級制度・評価制度・報酬制度の仕組みを一通りカバーした人事評価制度に改定しました。
こういった経緯により、事業・等級・評価を踏まえた目標設定に不慣れな社員が多く、制度改定後から3年が経過しようとする今でもまだまだ目標設定に苦戦する人が一定いる状態でした。目標設定する本人も慣れていないし、それを支援するマネージャーもどう支援していいか不慣れな状態です。
目標の設定の労力を減らしたいという課題があり、ここに対してAIを活用して支援をすることになりました。
2-2. 課題の整理
目標設定業務を、目的とギャップの視点で見直します。
- 業務の目的 : 社員一人ひとりが今期何に集中すべきかを明確にし、会社の成長と個人の自己実現を同期させること。
- 理想 : 全社員が納得感のある具体的な目標と達成計画を期初に保持し、迷いなく業務に取り組めている状態。
- 現状とのギャップ :
- 実務 : 目標を言語化する作業自体に時間かかっている。人によってはリテイクから修正を繰り返している。
- 品質 : 目標の粒度や質にばらつきがある。
- 心理 : うまく設定できないことに対して目標の設定に対して気が重い
また、細かな課題感は人によって異なり、多数の課題感全体をまとめて解決できるような解決策が理想でした。
2-3. インパクト予想
- メンバーの目標設定時間 : 6時間から2時間へ短縮。
- 人によっては元々目標の設定に苦戦しない人もいれば、リテイクを繰り返し、本人＋マネージャーの時間を膨大に使う人もいる。必要な時間には幅があるので、あくまで目安の時間
- 目標の解像度 : 上がることで、期中のアクションが明確になり、目標達成率や成果の質が向上する。
2-4. 構造整理
| カテゴリ | 項目 | 詳細内容 |
|---|---|---|
| インプット | 会社の前提情報 | 方針、カルチャー、課題、目標 |
| インプット | 評価制度 | 評価ルール、評価基準 |
| インプット | 部門の前提情報 | 方針、カルチャー、体制、部内の職種の Job Description (JD)、課題、目標 |
| インプット | 本人の前提情報 | 職種、所属部門、グレード、etc |
| プロセス | 目標の作成 | 評価制度のルールを踏まえ、部門やチームの方針・目標・課題、および個人の成長課題等を考慮して作成する。 |
| アウトプット | 目標 | 上司と期待値がマッチし、事業と個人の成長・成果につながる目標。 |
2-5. 実装
| カテゴリ | 大項目 | 中項目 | 詳細項目 / 内容 |
|---|---|---|---|
| インプット | ソース情報 | 全社 | 方針、カルチャー、課題、目標 |
| インプット | ソース情報 | 評価制度 | 評価ルール、評価基準 |
| インプット | ソース情報 | 部門 | 方針、カルチャー、体制、部内の職種の Job Description (JD)、課題、目標 |
| インプット | ユーザー入力 | 本人 | 職種、所属部門、グレード、etc |
| プロセス | 制御用プロンプト | ロール | 人事のエキスパートとして振る舞う |
| プロセス | 制御用プロンプト | 目標の素案作成 | 入力情報を基にJD、OKR、成長目標の素案を生成。各目標への詳細指示を含む。 |
| プロセス | 制御用プロンプト | 成長目標のレビュー | 入力された成長目標を特定の観点でレビュー。改善のための詳細指示を含む。 |
| プロセス | 制御用プロンプト | OKRのレビュー | 入力されたOKRを特定の観点でレビュー。模範的なOKRの特性に基づいた指示を含む。 |
| アウトプット | 目標の素案 | Job Description | 役割、業務 |
| アウトプット | 目標の素案 | OKR | Objectives, Key Results |
| アウトプット | 目標の素案 | 成長目標 | 目標、達成計画を項目別に記載 |
| アウトプット | 成長目標のレビュー結果 | 指摘項目 | 指摘事項、指摘箇所、修正例 |
| アウトプット | OKRのレビュー結果 | 指摘項目 | 指摘事項、指摘箇所、修正例 |
2-6. テスト
目標設定、成長目標のレビュー、OKRのレビューのそれぞれの機能に対して、いくつかのケースでテストを実施しました。当時、1つの事業部に伴走支援で業務に踏み込んで関わっていたこともあり、どんなメンバーがいて、どんな目標を元に仕事をするかについて一定の理解があったので、そのバリエーションに応じた検証を実施しました。
また、自分自身については解像度高く入出力を確認できるので。自分が利用する場合を想定したテストも実施しました。
2-7. 運用設計
2-7-1. 全社・部門の資料更新
目標設定は年次で実施しているため、年度単位で全社・部門の目標や課題に関するソース情報を更新する必要があります。また、年度の最中でも方針が変われば関連する情報は変更が必要です。大半の社員は年度開始に目標を設定しますが、中途入社で入ってくる社員は入社したタイミングに合わせて目標を設定することになるため、関連するソース情報は最新になっている必要があります。
2-7-2. 人事評価制度の資料更新
人事評価制度に変更があった場合も、関連情報を更新する必要があります。
2-8. リファレンス作成
ツールの利用方法に関するリファレンスを作成しました。目標設定支援ツールの場合、2種類のリファレンスを用意しています。
2-8-1. 社員向けリファレンス
目標を設定する各社員が参照するリファレンスを作成しました。
- 目標の素案作成方法
- 成長目標のレビュー方法
- OKRのレビュー方法
2-8-2. マネージャー向けリファレンス
目標設定支援ツールを管理する部門のマネージャー向けリファレンスを作成しました。
- 部門の前提情報のメンテナンス方法
- 関連ツールに部門のメンバーの権限を設定する方法
2-9. 受け入れテスト
複数の部門に受け入れテストの協力を依頼し、動作確認をしてもらいました。
正しく動くかというよりは、実際に有用に使えそうかという目線で活用してもらいつつ、使いにくい部分や不具合についてはフィードバックをもらいました。フィードバックを元に修正が必要な部分は修正し、内容に応じてリファレンスも最新化します。
2-10. アーキテクチャ資料の作成
社内へのノウハウ共有のために設計資料を作成しました。
| 大項目 | 中項目 | 説明 |
|---|---|---|
| ツールの全体像の図解 | Gem と NotebookLM の連携を含んだツールの全体像を図にする。 | |
| Gem | 役割 | Gem の役割を記載する。 |
| Gem | 機能 | Gem の機能を記載する。 |
| Gem | プロンプト | Gem のプロンプトを記載したファイルへの参照リンク。 |
| Gem | テクニック | プロンプトの設計に活用しているテクニック。 |
| Gem | 出力サンプル | Gem の出力サンプル。 |
| NotebookLM | 役割 | NotebookLM の役割を記載する。 |
| NotebookLM | 機能 | NotebookLM の機能を記載する。 |
| NotebookLM | ソース情報 | NotebookLM に設定するソース情報の一覧。 |
| NotebookLM | プロンプト | NotebookLM のプロンプトを記載したファイルへの参照リンク。 |
| NotebookLM | テクニック | プロンプトの設計に活用しているテクニック。 |
| NotebookLM | 出力サンプル | NotebookLM の出力サンプル。 |
| 設計のポイント | 全体に関する設計のポイント |
3. AIツール開発を成功させるポイント
技術の進化が速い世界で、継続的に価値を生むためのスタンスです。
3-1. 新機能の把握
モデルのアップデートや生成AIサービスの新機能により、新たな課題を解決できる可能性があります。できることを把握しておくことで「課題をAIで解決できそう」と思いつくことができる範囲が広がります。
3-2. 機能の検証
実際に手を動かして検証することで、プロンプトの限界値や精度を肌感覚で把握し、より確実な実装イメージを具体化します。
3-3. ユースケースの収集
他の人が公開している生成AIのユースケースを知ることで、自分の周囲でもその方法で解決できる対象があることに気づいたり、応用して解決できる範囲が広がりやすくなります。
3-4. 社内外への発信:
ノウハウやプロセスを公開することでフィードバックが得られ、改善につながります。
また、情報を提供する人のもとに情報が集まる傾向にあり、その後の生成AIの活用全般への加速装置となります。
まとめ
AIのモデルやツール自体は数年で代替されるかもしれません。しかし、業務の本質を見抜き、AIが解ける形に分解・整理した構造は、技術が変わっても使い続けられる普遍的な資産です。
まずは目の前の小さな業務の課題を構造化することから始めてみませんか。
