全社のAI刷新に取り組むために作成したAsIs・ToBe作成支援Coworkスキル

1. はじめに

クラスメソッドオペレーションズ株式会社では、AIや自動化などを組み込み、AIを中心とした業務へ刷新（以下「AI刷新」とします）するプロジェクトに取り組んでいます。その中で、私たちBGU（BPO推進ユニット）は、各部門の業務整理や改善手法の検討を伴走支援しています。

図の通りBGUは各部門のAI刷新を支援する役割です。現在の業務を整理するAsIsと、改善後の業務を設計するToBeの作成自体は、各部門で任命された部門推進者が担います。

そこでBGUがまず取り組んだのは、部門推進者がAsIsの整理やToBeの作成に着手しやすくすることでした。

この記事では、全社のAI刷新の取り組みの現状と、作成した二つのCoworkスキルを紹介します。あわせて、開発中のスキルに残っている課題と、今後の改善目標についても説明します。

なお、本記事に関連し「全社のAI刷新と、Coworkスキルを活用した伴走支援」というタイトルで2026/10/24のDevelopersIOのミニセッションに登壇予定です。

2. 全社のAI刷新と、現在取り組んでいること

AI刷新では、各部門が主要業務を整理し、改善対象を選び、改善後の業務を設計します。その後、試作と効果測定を行い、運用への定着や他の業務への展開を進める計画です。

業務を見直す方法は、AIへの置き換えだけではありません。不要な作業をなくす、似た作業をまとめる、順序や担当を変える、作業を簡単にするというECRSの考え方を参考に検討します。AIや既存システムによる自動化は、その検討を踏まえて選ぶ手段です。

こうした検討のためには、まず現在の業務を関係者が確認できる形に整理する必要があります。誰が何を行っているか、どの情報を使って判断しているか、どこで待ちや手戻りが発生しているかを共有したうえで、改善後の業務を考えます。

全社のAI刷新の進捗としては、現行業務（AsIs）の整理を進めつつ、自分たちの業務の適切な流れ（ToBe）の作成に入り始めている段階です。

3. Coworkスキル開発の背景

スキルの作成にあたって最初に考えたのは、部門推進者の作成負担をどう減らすかということでした。

Coworkスキルを開発したのは白紙に地図を描くことがもっとも難しいと考えたからです。
各部門の担当者は、自分たちの仕事の流れや手順を理解しています。しかし、業務を理解していても、一から業務フローや改善案を一つ一つ書き上げるのは簡単ではありません。また日々の業務に追われるなかでは取り組む時間も限られています。

業務整理や改善設計に慣れていなければ、何から書き始め、どこまで詳しく整理すればよいか迷うこともあると思います。その結果、最初の一歩を進めにくくなるのではないかと考えました。

そこでBGUでは、既存のマニュアルなどをもとにAIがたたき台を作り、部門推進者が内容を確認・修正しながら進められるスキルを開発することにしました。

AIが整理した案や仮説を見ながら、「実際はどうか」「どこを変えたいか」を考える進め方です。何を書くかから考えるのではなく、この提案をどう修正すれば実際の業務になるのかという思考に切り替えられるため、進めやすくなると考えました。

4. AsIsスキルの詳細

まず着手したのはAsIsスキルでした。

スキルの作成では、BGUがこれまでの業務改善支援で得た知見に加え、クラスメソッドのビジネス変革部の皆さまから学んだ、AsIs・ToBeの作成方法を取り入れました。
ワーキングでは、実際の業務改善で使用されている資料をもとに、業務の整理方法やフローの表現方法を学びました。これらを参考に、スキルの作成手順や出力形式を検討し、業務フローの図形や注記、ページ構成などに反映しています。

また、各部門が持つマニュアルや業務一覧を入力資料として使い、AIがたたき台を整理し、部門推進者が確認・修正する進め方にしました。

クラスメソッドオペレーションズはリモートワークを主体としており、マニュアルや手順書、業務一覧など、現在の業務を説明する資料がデータやオンライン上で情報化されています。そうした資料からAIが業務の情報を整理し、不足する部分について仮説や確認事項を提示します。

部門推進者はAIに回答・修正する形式としました。

マニュアルだけでは分からないことを確認する

ただし、マニュアルや業務一覧が、業務全体の流れを表しているとは限りません。

例えば、画面操作が詳しく書かれていても、他部門が受け持つ業務や承認の条件、例外時の対応が省略されている場合があります。また、マニュアルが古くなり、現在の運用と違っている可能性もあります。

そのため、スキルの開発では、AIの出力をそのまま確定した情報として扱わず、人が内容を確認・承認することを重視しました。

以下は、架空の申請受付業務を使った説明例です。

マニュアルに「メールを開く」「申請内容を確認する」「管理台帳を開く」「必要事項を入力して保存する」「承認者へメールを送る」と書かれていたとします。

これらをすべて別の箱にすると、操作手順が並ぶ図になります。スキルでは、担当や判断、情報の入出力を確認しながら、業務の作業単位にまとめます。

ただし、この整理だけでは、申請に不備がある場合の対応や、承認後の処理は分かりません。そこでAIが確認事項を整理し、部門推進者が業務担当者と内容を確かめます。

例えば、「不備がある場合は誰に戻すか」「修正後にもう一度確認するか」「何をもって受付完了とするか」といった点です。回答に合わせて作業や分岐を追加・修正します。

Coworkから出力されるスイムレーンの一例
（スキルでは業務全体の流れ＋スイムレーンの2種が出力されます）

上記はスイムレーンの出力例です。
部門推進者は、出てきた案を見ながら、業務担当者と「この作業は実際にあるか」「担当者は合っているか」「この条件ではどうするか」を確認します。自分たちの業務が正しく表現されているかは、人が判断します。

資料に直接書かれている内容と、AIが推測した内容も区別して記録します。実務担当者が確認していない情報を、確認済みの事実として扱わないようにしています。

図にする前に、文章で内容を確認する

AsIsスキルでは、最初からスイムレーン図を描くのではなく、まず業務内容をMarkdown形式の文章で整理し、その内容を確認する構成にしました。
スイムレーン図は、担当者や部門ごとに領域を分け、誰がどの作業を行うかを示すフロー図でわかりやすい反面、図として起こしてしまうと「なぜそのフローになっているか」が捉えづらいと考えたためです。
また、これはやり取りする情報を整理してトークン使用量を抑えることや、整理した文章内容があればAIが理解しやすくToBeスキルでも活用できるという意図もありました。
そのためまずは文章で整理した内容を部門推進者が確認・承認した後に、PowerPointなどのフロー図へ変換する工程にしました。

なお、描かれた図についてはまだまだ課題が残っているのが実情です。この点は後の章で説明します。

5. ToBeスキルの詳細

次にToBeスキルの作成では、AIや自動化への置き換えを先に決めず、まずECRSの原則に沿って業務を見直すことを考えました。

AI刷新という目的に対して、AI化を前提にしないのは違和感があるかもしれません。しかし、AI化や自動化は業務をより良くするための手段だと思います。

作業自体が不要なら、AIや自動化で処理を続けるよりも、作業をなくすほうが適切です。新たな仕組みを導入すれば、保守や管理の作業も発生します。AIやシステムは利用すればするだけコストもかかります。

そのため、AIが作る改善案も、最初に作業を見直してから、AIや自動化の役割を考える順序にしました。

作業を見直してから、役割分担を考える

改善案は、ECRSの考え方に沿って、次の順番で検討します。

現在の作業をすべて残したままAIへ置き換えるのではなく、まず必要な作業かを考えます。そのうえで、残る作業を人、AI、通常の自動化でどう分担するかを検討します。

現実案と理想案を比較する

スキルでは、原則として「現実的・段階導入案」と「AI最大活用・理想案」の二つを作成する形にしました。

現在の体制やシステムで進めやすい案と、AIエージェントなどを活用して人の入力・転記・確認をできる限り減らす案を比較するためです。

先ほどの架空の申請受付業務なら、次のような方向を検討できます。

これらは説明用の候補です。実際の案は、対象業務の事実や制約を確認して作成します。

AIを多く使うことだけを理由に、理想案を推奨するわけではありません。期待する効果に加え、費用、導入期間、他部署との調整、運用上のリスクを比較します。

どちらか一つを選ぶだけでなく、理想案を将来の目標にし、現実案から段階的に進めることも想定しています。

AsIsフローから2案のToBeをAIが出力します。AI案が可能かも含めて部門や関係者と確認する想定です。

最終的なフローの前に、関係者が判断する資料を作る

ToBeスキルでも、まずテキストで検討内容を整理します。さらに、最終的なToBeフローを作る前に、案を比較して関係者に確認してもらうためのPowerPoint資料を作成します。

これは、ToBeを部門推進者だけでは決定できないためです。
担当や業務ルールの変更などについて、部門内や関係部署との調整が必要になります。
スイムレーン図は業務の流れを理解するのに役立ちます。
一方で、改善案を複数人が判断するには、「目的」「現在の課題」「変更する理由」「実現に必要な条件」も確認する必要があります。

そのため、これらを確認できる資料を作り、目指す方向を選んだ後に、詳細なToBeフロー図を作成する順序にしました。必要に応じて、関連IT部門などに技術的な実現方法も確認します。

スキル上で内容を確認して次へ進むことと、組織として承認されたことは区別しています。AsIs・ToBeのどちらでも、「この内容でよい」と人が判断することを重視しています。

6. スキルの課題と今後の改善目標

現時点では、二つのスキルの出力を、部門推進者が確認・修正するたたき台として提供しています。

たたき台という位置づけには、二つの意味があります。

一つは、AIが整理した業務内容や改善案を、部門推進者や業務担当者が確認する必要があることです。この確認は、今後も作成の過程に必要だと思います。

もう一つは、フロー図の出力に課題があり、線の分岐が重なってしまったり文字がボックスからあふれるなど、人による手直しが必要なことです。複雑な条件を含む業務を、図形と接続線で読みやすく表現する部分は、まだ十分ではありません。

Markdownで内容を整理していても、その内容を図へ適切に反映できているかを確認し、必要に応じて図を修正する作業が残っています。

上記のようにそのまま出力されたものはレイアウトに問題があり、修正した上で分かりやすいように色を付けています。

対話で修正した内容を、図にも反映したい

今後は、複雑な条件を含む業務でも、対話で確認・修正した内容をフロー図へ適切に反映できるように改善したいと考えています。

利用者が作業や分岐の修正を伝えれば、その内容に合わせて図形や接続線も更新され、PowerPoint上で一つひとつ手直しする負担を減らせる形が目標です。

そのために、複雑な分岐や差し戻しを含む業務の例を使い、整理した仕様と生成した図が一致しているか、関係者が流れを読み取れるかを確認していきます。

あわせて、質問の内容や出し方も見直します。最初から大量の情報を求めるのではなく、手元の資料から整理できる部分を示し、不足している点を順に確認できるようにしたいと考えています。

7. 各部門が業務改革を進めるために

BGUが最初に取り組んだのは、各部門の部門推進者がAsIs・ToBeを作り始めやすくすることでした。

既存資料からAIがたたき台を整理し、部門推進者が業務担当者と確認・修正します。改善案も、候補を比較しながら関係者が目指す方向を選びます。この進め方を支援するために、2つのCoworkスキルを開発しています。

現在は図の出力にも課題があり、完成資料としてそのまま使える段階ではありません。
これから先も、業務内容の確認と改善案の検討は人が行うという原則は守りつつ、資料の整形や再描画はできる限りスキルで対応できるように、改善を続けていきます。

クラスメソッドオペレーションズ株式会社について

クラスメソッドグループのオペレーション企業です。

運用・保守開発・サポート・情シス・バックオフィスの専門チームが、IT・AIをフル活用した「しくみ」を通じて、お客様の業務代行から課題解決や高付加価値サービスまでを提供するエキスパート集団です。

当社は様々な職種でメンバーを募集しています。

「オペレーション・エクセレンス」と「らしく働く、らしく生きる」を共に実現するカルチャー・しくみ・働き方にご興味がある方は、クラスメソッドオペレーションズ株式会社 コーポレートサイトをぜひご覧ください。※2026年1月 アノテーション㈱から社名変更しました。