前回のAI社員実践記では、Cloudflare OSを使ってオフィスピコッツ専用の「PIKOZ OS」を作り、AIに「顧客フォロー管理アプリを作って」と頼んでみました。
結果は想像以上でした。
日本語で欲しい機能を説明しただけで、顧客の追加・編集・削除ができ、データも保存できるWebアプリが実際に完成しました。
ただ、そこで一つ疑問が残りました。
「作れることは分かった。でも、このアプリを本当に仕事で使う必要があるのか？」
顧客名や次回連絡日を管理するだけなら、Googleスプレッドシートでもできます。
そこで今回は、もっとオフィスピコッツの実際の仕事に近いものを作ってみることにしました。
選んだのは、当社が運営している「京都・滋賀プレスリリース」の掲載案件管理です。
今回は単なるテストデータではありません。
本当に進行しているプレスリリース案件をPIKOZ OSに入れて、どこまで仕事を任せられるのか。
実際に試してみました。
今回作ったのは「プレスリリース案件管理アプリ」
京都・滋賀プレスリリースでは、掲載相談をいただいてから公開するまで、だいたい次のような流れがあります。
掲載相談
→ 情報確認
→ 原稿作成
→ サンプル作成
→ 先方確認
→ 修正
→ 公開
→ 公開後の連絡
案件が増えると、
「今どこまで進んでいたか」
「何を確認する必要があったか」
「サンプルを送ったか」
「公開URLはどれか」
といった情報を案件ごとに整理する必要があります。
そこでPIKOZ OSに、
「京都・滋賀プレスリリースの案件管理用Gadgetを作ってください」
と依頼しました。
管理したい項目として、
事業者名、担当者名、地域、掲載内容、Instagram、元投稿URL、イベント日、ステータス、確認事項、サンプルPDF、公開URLなどを指定しました。
すると今回も、AIがその場でアプリを作り始めます。
そしてしばらくすると、プレスリリース案件を一覧で管理できる画面が完成しました。
ここまでは前回と同じです。
問題は、本当の仕事で使えるかどうかです。
AIが作った分類が、実際のサイトと違っていた
まず案件を登録しようとして気づきました。
AIが作った「ジャンル」や「業種」が、実際のlocalpr.jpで使っている分類と違っていたのです。
たとえば、実際のリリースカテゴリには、
「イベント・キャンペーン」
「製品・サービス」
「開店情報」
「人事・組織」
「受賞・表彰」
などがあります。
業種にも、
「地域活動・子育て支援」
「教育・学習」
「観光・宿泊」
「農業・畜産・食品」
「飲食」
など、実際にサイトで使用している分類があります。
AIは、こちらの業務を知らない状態で「それらしい分類」を作っただけです。
そこでWordPressの実際の管理画面を見ながら、PIKOZ OSへ修正を指示しました。
さらに「地域」についても確認すると、localpr.jpでは、
その他地域
京都
滋賀
関西
という分類を使っていました。
これも同じ内容になるよう修正しました。
この時点で一つ分かったことがあります。
AIに業務アプリを作らせても、実際の業務ルールとの照合は人間が必要です。
見た目がそれらしく完成していても、本当に使えるアプリになっているとは限りません。
本物の案件を登録したら「保存」が動かなかった
分類を整えたあと、実際の掲載相談案件を登録してみました。
今回使ったのは、京都市西京区の正恩寺で親子リトミックを開催するという案件です。
事業者名、地域、リリースカテゴリ、業種、Instagram URLなどを入力します。
そして「保存」をクリックしました。
ところが、
何も起こりません。
ボタンを押しても画面が閉じず、案件も登録されませんでした。
画像：保存ボタンを押しても反応しない
そこでChromeの開発者ツールを開いてエラーを確認してみました。
すると、フォーム送信がiframeの制限によってブロックされていることを示すエラーが出ていました。
そのエラー内容をそのままPIKOZ OSへ渡して、
「通常のフォーム送信を使わず、既存の保存処理をJavaScriptから呼び出す形に修正してください」
と頼みました。
AIがコードを修正。
再び保存してみると、
今度は案件が正常に登録されました。
これはなかなか面白い体験でした。
AIが作ったアプリに不具合があり、その原因を確認し、その不具合を作ったAI自身に修正させる。
従来の業務システムでは、制作会社やエンジニアへ修正を依頼する場面です。
今回は会話だけで修正できました。
案件を登録しただけでは、まだ「案件管理表」
次に考えたのは、
「これだけなら普通の案件管理システムと同じでは？」
ということです。
そこで、PIKOZ OSのAIに登録済み案件についてこう聞いてみました。
「この案件でプレスリリース原稿を作るために、不足している情報を整理して」
するとAIは、Gadgetに登録されている案件情報を読み取り、
現在分かっている情報と、足りない情報を分けて提示しました。
ここで初めて、
案件管理アプリ＋AI
という組み合わせの意味が出てきました。
単に一覧を保存するだけではなく、
「この案件で次に何を確認すればいいか」
をAIが考え始めたからです。
Instagram投稿本文を入れると、AIが内容を読めるようになった
最初は案件の概要欄を十分に入れていなかったため、AIはかなり多くの情報を「不足」と判断しました。
そこで、掲載相談のきっかけになったInstagram投稿本文を、そのまま「掲載内容の概要」に登録しました。
そしてもう一度、
「すでに登録済みの内容は聞き直さないでください」
と条件を付けて不足情報を整理させます。
すると回答内容はかなり変わりました。
念のため、
「Gadgetに保存されている『掲載内容の概要』を実際に読めているのか」
も確認してみました。
AIに、
「掲載内容の概要の冒頭200文字をそのまま表示してください」
と頼むと、保存した本文を正しく表示しました。
つまり、PIKOZ OSはGadgetに保存した案件データを実際に参照できています。
ここまで来ると、案件管理アプリとしてはかなり面白くなってきました。
ただし、AIは「一般的なプレスリリース」を作ろうとする
次の問題は、文章作成でした。
AIに不足情報を整理させると、
担当者名
開催日時
参加費
対象年齢
定員
申込方法
事業者概要
など、一般的なイベント告知として「あった方がいい情報」を大量に挙げました。
しかし今回の記事は、
「正恩寺で親子リトミックを開催することが決まった」
という開催決定のお知らせです。
参加者募集の記事ではありません。
開催日時や料金がまだ記事に含まれていなくても、記事の主題そのものは成立します。
そこでPIKOZ OSへ、
「開催決定のお知らせ」と「具体的な開催告知・参加者募集」は別の記事タイプとして考えること、
そして、
一般的なプレスリリースとして欲しい情報ではなく、localpr.jpとして今ある情報で記事化できるかを判断すること
を教えました。
すると、AIの判断はかなり改善しました。
実際の公開済みプレスリリースを読ませてみた
それでも、作られる原稿は普段localpr.jpで公開している記事とはかなり違います。
そこで思いました。
「ルールを一つずつ説明するより、実際に公開した完成稿を読ませた方が早いのでは？」
試しに、すでにlocalpr.jpで公開しているプレスリリースページのURLをPIKOZ OSへ渡しました。
今回最初に読ませたのは、「癒しの森 in 近江勧学館」の出店者募集記事です。
PIKOZ OSへ、
「URL文字列から推測せず、実際のページ本文を取得できた場合だけ分析してください」
と指示しました。
すると、
タイトル
リード文
記事内の見出し
出店料
申込方法
キャンセルについて
開催概要
主催者情報
まで、実際の公開ページから読み取ることができました。
これはかなり大きな発見でした。
URLを渡すだけで、過去の完成稿を教材として使える。
そこで、イベント開催、出店募集、店舗オープン、事業者紹介、新サービスなど、タイプの違う公開済み記事を6本読ませました。
そして、
「これらを比較して、京都・滋賀プレスリリース独自の編集ルールを抽出してください」
と頼みました。
AIは、
タイトルの付け方
リード文の作り方
本リリースのポイント
本文の見出し構成
概要ブロック
関連リンク
第三者的表現を避けるルール
記事タイプごとの構成
などを整理し、
「京都・滋賀プレスリリース 編集ルール v1」
を作りました。
さらに内容を確認しながら、
「情報がないからといって未決定と判断しない」
「今後Instagramで案内すると勝手に補わない」
「本リリースのポイントは必ずしも必要ではない」
「開催決定のお知らせと参加者募集を分ける」
といったルールを追加し、v1.1まで整えました。
過去の完成稿まで読ませれば、原稿は使えるようになったのか
ここが一番知りたかったところです。
公開済み記事を6本読み、編集ルールまで作ったAIに、正恩寺案件の原稿をもう一度作らせました。
結果は、
かなり改善しました。
最初は数行しかなかった本文も、
主催者がお寺ヨガに通った経験、
子連れでお寺を訪れる機会が少ないと感じていること、
子どもと一緒にお寺を知るきっかけにしたいという思い、
パラバルーンの使用許可を得ていること
など、元のInstagram投稿に含まれている一次情報を使って文章を組み立てられるようになりました。
ただし、
まだそのまま公開できる品質ではありませんでした。
たとえば、
元投稿では「お寺という場所に憧れていた」というニュアンスなのに、
「正恩寺での開催に以前から憧れていた」
という意味に少し変わってしまう。
また、
情報が登録されていないだけなのに、
「まだ決まっていない」
と判断してしまうこともありました。
こちらが「推測しない」と強く教えると、今度は一次情報まで削ってしまい、極端に短い原稿になることもありました。
逆に文章量を増やすよう頼むと、AIが自然な文章にしようとして、元情報の意味を少し広げてしまう。
このあたりは、かなり注意が必要です。
今回の評価
今回の実験を、実際の業務に使えるかという視点で整理すると、私はこう評価します。
案件管理：○
案件の追加、編集、削除、ステータス管理は問題なく使えそうです。
案件情報をAIが読む：○
Gadgetに保存した掲載内容やURLなどをAIが参照できました。
不足情報の整理：○
記事化するために何が不足しているかを整理する用途には十分使えそうです。
公開済み記事の分析：○
localpr.jpの実際の公開URLを渡し、ページ本文を読み取って構成や編集方針を分析できました。
編集ルールの抽出：○
複数の完成稿から、自社独自の編集ルールを作ることもできました。
プレスリリース完成稿作成：△
たたき台としては使えます。
しかし、現時点では人間が意味のズレや推測を細かく確認する必要があり、「そのまま公開できるAI編集者」にはまだ届いていません。
「AIに仕事を教える」とは、思っていたより奥が深い
今回面白かったのは、単にプロンプトを長く書けば解決するわけではなかったことです。
最初は、
「第三者的な表現を使わない」
「推測しない」
とルールを追加していきました。
しかし、ルールを強くしすぎると文章が短くなる。
文章量を増やせば、今度は意味を補完する。
そこで実際の完成稿を読ませて、自社独自の編集方針を抽出させました。
それでも、人間の編集者と同じ判断を安定して行えるところまでは届いていません。
これは失敗というより、
AI社員に業務を任せるなら、「仕事の手順」だけでなく「判断基準」まで教える必要がある
ということが分かった実験でした。
Cloudflare OSだからできた部分も大きい
今回使っているPIKOZ OSは、Cloudflare OSをベースにしています。
Cloudflare Workersは、アプリケーション処理を実行できるサーバーレス基盤で、Durable Objectsを使った状態管理やWorkers AIなどを組み合わせられます。CloudflareのWorkers Paidプランは現在、アカウントあたり最低月額5ドルです。
Workers AIには無料利用枠があり、それを超えた場合はモデル利用量に応じた料金体系になっています。
またAI Gatewayでは、AIへのリクエストに対してキャッシュ、レート制限、ログなどを管理できます。
今回のように、
業務用アプリを作る
→データを保存する
→AIにそのデータを読ませる
→AI自身にアプリを修正させる
という使い方が、一つの環境内でできる点は非常に面白いところです。
今回の結論
第5話では、
「AIに業務アプリを作ってと頼んだら、本当にアプリができた」
というところまで試しました。
第6話では、その先へ進んで、
「では、そのアプリを本当の仕事に使えるのか？」
を試しました。
結果は、
使える部分はかなりある。ただし、AIに完成原稿まで全部任せるにはまだ早い。
というものです。
案件管理、情報整理、不足情報の洗い出し、過去記事の分析などは、すでに実務で使える可能性を感じました。
一方、公開する文章については、現在のモデルでは人間による確認と編集が欠かせません。
でも今回一番面白かったのは、
AIが単に文章を書くのではなく、自分が仕事をするためのアプリを作り、そのアプリに保存された情報を使いながら仕事を進め始めた
ことです。
これは、これまでのChatGPTの使い方とは少し違います。
「質問すると答えるAI」から、
「自分専用の仕事場と道具を持つAI社員」
へ近づいているようにも感じます。
ただし、本当の社員と同じです。
仕事を渡しただけでは、こちらのやり方までは分かりません。
過去の実績を見せ、判断基準を教え、間違ったところを直す。
そこまでして初めて、自社の仕事を理解し始めます。
今回の実験は、まさにその途中でした。
次は「モデルを変えたらどうなるか」を試したい
今回使ったAIモデルでは、アプリ作成や修正はかなりうまくできました。
一方で、日本語のプレスリリース原稿については、まだ人間の編集がかなり必要です。
Cloudflare AI GatewayはCloudflare上のモデルだけでなく、OpenAIやAnthropicなどの第三者モデルも同じ仕組みから利用できる構成を提供しています。
そこで次に試したいのは、
同じ案件管理アプリ、同じ一次情報、同じ編集ルールを使い、文章を書くAIモデルだけ変えたらどうなるのか。
です。
アプリを作るのが得意なAIと、文章を書くのが得意なAI。
もしかすると、AI社員も人間と同じように、
仕事によって担当を分けた方がいいのかもしれません。
この続きは、また実際に試してみます。
AI社員実践記は、まだ続きます。
あなたの会社なら、AI社員にどの仕事を任せますか
今回試したのは、プレスリリースの案件管理でした。
AIに業務アプリを作らせ、実際の案件を登録し、保存された情報を読ませ、さらに過去の完成稿まで参考にしながら原稿作成に挑戦しました。
結果として、案件管理や情報整理、不足情報の洗い出しにはかなり使える一方、公開原稿をそのまま任せるには、まだ人の確認や判断が必要だということも分かりました。
AI活用は、「何でもAIに任せる」ことではありません。
今の仕事のどこをAIに任せると楽になるのか。どこは人が判断すべきなのか。そもそも専用のAI社員を作る意味があるのか。
オフィスピコッツでは、そうしたところから一緒に整理しています。
また、ChatGPTなどを使ってホームページを修正しているうちに表示が崩れた、元に戻せなくなったという場合は、AIレスキューもご覧ください。
京都産業21 登録専門家（No.46）／滋賀県DX協創パートナー／デジタル庁 デジタル推進委員。2002年開業、創業25年目。京都・滋賀を中心に1万件超のWeb活用・制作に携わる。 会社概要を見る