AIを使うべき仕事と、使わなくていい仕事– Arkanos Insights

AIを使えば、もっと簡単になる？

以前、Arkanos Insightsで「Docs as Codeってなんだ？ ― ドキュメント制作はどう変わるのか」という記事を公開しました。

その中で、開発者がMarkdownで作成した製品仕様書から、必要な情報を抽出してHTMLマニュアルを生成する例を紹介しています。

このような話をすると、「AIを使ってマニュアルを自動生成すればよいのでは？」という考えも浮かびます。

もちろん、それも一つの方法です。しかし、仕様書の中で必要な情報があらかじめ識別されているなら、簡単なスクリプトで該当部分を抽出し、HTMLに変換するだけで済みます。

そこに、わざわざAIを使う必要はあるのでしょうか。

今回は、この例を出発点に、AIを使うべき仕事と、従来のプログラムで十分な仕事の違いについて考えてみます。

必要な情報が決まっているなら、プログラムで取り出せばいい

例えば、Markdownで作成された製品仕様書に、次のような記述があるとします。

---

# 製品仕様書

## 内部処理
開発者向けの内部仕様を記載します。

<!-- manual:start -->
## 初期設定

1. 電源を接続します。
2. 設定画面を開きます。
3. ネットワーク情報を入力します。
<!-- manual:end -->

## エラー処理
内部的なエラー処理について記載します。

---

マニュアルに掲載する情報が <!-- manual:start --> と <!-- manual:end --> の間にあると決まっていれば、プログラムはその範囲を取り出すだけです。

取り出したMarkdownをHTMLに変換すれば、簡易的なマニュアルを生成できます。

この処理に、文章の意味を理解する能力は必要ありません。あらかじめ決められた規則に従って、必要な部分を抽出すればよいからです。

もちろん、実際の運用では、タグの記述漏れや複数箇所からの抽出、画像の参照先なども考慮する必要があります。それでも、何を取り出すかが明確に決まっているなら、従来のプログラムで処理する方が、結果を予測しやすく、動作も検証しやすいでしょう。

AIを使うと、同じ指示を与えても出力が変わる可能性があります。必要な情報が省略されたり、元の仕様書にない説明が追加されたりすることも考えられます。

決められた範囲を、そのまま取り出す。

それだけの処理に、文章を解釈して生成する仕組みを持ち込む必要はありません。

では、AIを使う意味があるのはどんなときか

同じ製品仕様書でも、マニュアルに必要な情報が明確に区別されていない場合はどうでしょうか。

例えば、仕様書のさまざまな箇所に、利用者向けの操作説明、開発者向けの内部仕様、設定項目の説明、制約事項などが混在しているとします。

そこから利用者に必要な情報を探し出し、読み手に合わせて説明を組み立てるには、単に決められた文字列を抽出するだけでは足りません。

従来のプログラムでも、条件を細かく定義すれば、ある程度の処理は実現できるでしょう。しかし、文書の書き方や構成が一定でなければ、例外に対応するためのルールが増え、プログラムの開発や保守に手間がかかります。

このような場面では、AIが選択肢になります。

例えば、仕様書から利用者に必要な情報の候補を抽出する、専門的な記述を利用者向けの文章に書き換える、不足している説明を洗い出す、といった使い方です。

ただし、AIが生成した文章を、そのまま正しい製品仕様として扱うことはできません。特に、操作手順や安全上の注意、製品の制約事項などは、元の仕様との照合や担当者による確認が必要です。

AIの価値は、確認作業をなくすことではなく、従来は人間が一つずつ読み解いていた情報の整理や文章化を支援できることにあります。

「プログラムでできるならAIは不要」とも限らない

ここまでの話だけなら、従来のプログラムで実現できる処理にはAIを使わなければよい、という結論になりそうです。

しかし、実際の業務では、もう少し考える必要があります。

例えば、取引先ごとに書式が異なる大量の帳票から、必要な項目を取り出す仕事を考えてみます。

書式が一種類で、項目の位置も決まっているなら、従来のプログラムで処理しやすいでしょう。

一方、書式が何十種類もあり、取引先によって項目名や配置が異なる場合はどうでしょうか。

従来のプログラムでも、書式ごとに抽出ルールを作れば対応できるかもしれません。しかし、新しい書式が増えるたびにルールを追加し、変更に追従し続ける必要があります。

この場合、AIによる情報抽出の方が、仕組み全体の構築・保守にかかる負担を減らせる可能性があります。

もちろん、AIにも誤抽出のリスクがあるため、金額や日付など、誤りが許されない項目には検証の仕組みが必要です。

つまり、判断基準は「従来のプログラムで実現できるか、できないか」だけではありません。

従来のプログラムで十分な品質と効率を実現できるか。AIを使うことで、構築・運用・検証を含めた全体の負担を減らせるか。

そこまで考えて、初めて適切な方法を選べるのだと思います。

AIを導入すると、新たに必要になる仕事もある

AIを使えば、人間が行っていた作業の一部を自動化できる可能性があります。

しかし、AIを導入することによって、新たな仕事が発生する場合もあります。

例えば、次のようなものです。

• AIに渡す情報や指示を整備する
• 出力結果が正しいかを検証する
• 誤りや想定外の出力があった場合の対処方法を決める
• モデルや利用環境の変更による出力への影響を確認する
• 利用料金や処理時間、情報の取り扱いを管理する

これらを含めても、従来の方法より効率的になるのであれば、AIを導入する意味があります。

反対に、単純な処理をAIに置き換えた結果、出力結果の確認や修正に時間を取られるようでは、業務全体として効率化できたとは言えません。

AIを使って処理する部分だけでなく、その前後に人間が何をしなければならないのかまで含めて考える必要があります。

AIと従来のプログラムを、組み合わせてもいい

AIを使うか、従来のプログラムを使うか。

この二つは、必ずしもどちらか一方を選ばなければならないものではありません。

例えば、仕様書からマニュアルを生成する工程でも、次のような役割分担が考えられます。

1. 決められたタグや構造に従って、スクリプトで情報を抽出する
2. 抽出した文章について、AIで分かりにくい表現や説明不足の候補を洗い出す
3. 開発者が提案内容を確認し、必要な修正を行う
4. 確定したMarkdownを、プログラムでHTMLに変換する

情報の抽出や形式の変換など、規則が明確な処理は従来のプログラムに任せる。

文章の意味を踏まえた確認や改善案の作成など、規則だけでは扱いにくい処理にはAIを活用する。

そして、製品仕様として何が正しいのか、どの説明を採用するのかという判断は、担当者が行う。

それぞれの得意な部分を組み合わせれば、何もかもAIに任せる必要はありません。

AIを使うことを、目的にしない

AIは、従来のプログラムでは難しかったことを実現するための選択肢であって、従来のプログラムで十分な処理を置き換えるためのものではない。

前の記事で触れたこの考え方は、ドキュメント制作以外の業務にも当てはまります。

ただし、「従来のプログラムでできることには、絶対にAIを使わない」という意味ではありません。

ルールを作り続けるよりも、AIを使った方が柔軟に対応できる場合もあります。反対に、AIを使うより、数行のスクリプトを書いた方が確実で簡単な場合もあります。

大切なのは、最初から「AIで何をするか」を考えるのではなく、「何を実現したいのか。そのために、どの方法が適しているのか」という順番で考えることです。

AIを使うべき仕事を探すのではなく、今ある仕事の中で、AIを使うことに意味がある部分を見極める。

その判断ができて初めて、AIは業務を改善するための道具になるのではないでしょうか。