
こんにちは、けんちろです。今週も、僕の仕事を少しずつAIへ移しています。9月5日から9月12日までの記録を振り返ります。台帳によると、定期処理からのAI起動は152回でした。
今週は、LINEの返信案作成もAIに任せることにしました。「LINEに来たメッセージにも、Slackと同じように対応してほしい」と頼みました。受信した内容を、事務を任せているAIに渡し、返信案を作るところまで仕組みをつなぎました。
ただ、つないだら終わりではありませんでした。本文は届くのに返信相手が分からない。手順書を見直すAIが、変化のない週にも動く。公開した週報は、僕が書き手なのにAIの発言のように読める。今週は、そういう食い違いを直した週でもあります。
まず数字から
152回は、定期処理から起動した分を台帳で数えた数字です。僕がAIに話しかけた回数の総計ではありません。内訳には、写真を扱う処理の55回、Discordへの返信処理の30回、Slackの確認処理の19回などが入っています。
一方、AIを使わないスクリプトも動いています。予約カレンダーの公開チェックは110回、実際に更新したのは26回でした。週間プランの通知は24回、予定変更による貼り直しは18回です。
AIを起動した回数と、AIを使わずにスクリプトで確認した回数は分けて見ています。カレンダーを確かめるたびにAIを呼んでいるわけではないんですよね。今週の記録にも、AIが関わる処理と、スクリプトだけで済む処理の両方が残っています。
9月5日(土)—— Notionへ渡した表が、表になっていませんでした
Notionに載った文章を見ると、表にしたはずの部分に縦棒や区切り線がそのまま出ていました。プログラムの例を囲む記号も、文字として残っていました。僕は修正を頼みました。
本文は保存されています。でも、表としては読めません。原因は、原稿をNotionの表やコードの表示形式に変換する処理がなかったことです。本文が入ったことと、表として読めることは別でした。
AIは、Notionへ書き込む共通の処理を直しました。縦棒と区切り線で書いた部分はNotionの表に変換し、プログラムの例はコードとして表示できるようにしました。同じ処理を使っていた調査記事、週次報告、ToDoの登録などにも修正が入りました。
これから書く分だけでは足りません。過去記事も9本修復しました。直したのは、表38個、コード部分21個です。原稿を作る指示と手順書にも、表の書き方を追記しました。表には区切り線を入れ、スマホで読む表は列を4つまでにします。
「保存しました」と返ってきても、僕が読めるとは限りません。この話は、「保存しました」は完了ではないという記事にも通じます。今週は置き場所だけでなく、置いたあとの見え方を直しました。
9月5日(土)—— 僕が求めたのは、承認を増やすことではありませんでした
この日、AIの誤った料金報告への対策も整理しました。AIは動画サービスの文字起こしを「無料です」と報告して実行していました。実際には69分の文字起こしに6.98ドルがかかっていました。残高がマイナスになり、カードから自動でチャージされていました。僕が13.38ドルの請求書を見せて、この間違いが発覚しました。
なぜ気づけなかったのか。AIは、料金ページの「全機能追加料金なし」という説明を読んで、文字起こしも無料だと判断していました。文字起こしを使おうと決めたあとに料金を調べ、無料と読める説明を採用していたんです。実際にいくら減るのかを確かめていませんでした。
AIが出した対策案も、僕は差し戻しました。承認を求めるようにする、金額の上限を付ける、報告に根拠を添える。どれも、「無料です」という報告が間違っていた理由への答えになっていなかったからです。
僕が「無料です」と聞いて承認しても、同じようにお金はかかります。僕の承認を挟むだけでは、この間違いは防げません。そこで僕は、こう伝えました。
後戻りが効かないものに対して、推測ですすめるのはNGです。確実な1次情報がある状態で進めるか、小さく試してテストするかを徹底してください。
AIは、このサービスの自動文字起こしを禁止にし、手順と実行に使ったスクリプトを削除しました。お金が動く経路の台帳も作り、単価、残高の読み方、実測値を残しました。加えて、残高の週次点検や広告費の監視も入れています。
そのうえで、戻せる作業についても指示しました。サイトの更新のように戻せるものは、できるだけ僕の手を使わず、承認なしで進めてほしい、と。怖くなって何も進まなくなったら、仕事を任せている意味がなくなります。
止める場所は、僕が決めておく
- 戻せない操作は、推測だけで進めない。確かな情報を取るか、小さく試して実際の結果を確かめる。
- 承認を挟んだことだけで安心しない。僕へ届く説明が間違っていれば、同じことが起きる。
- 戻せる作業は進める。確認を増やすことが目的にならないよう、両方の指示を並べて残す。
9月5日(土)—— スマホとパソコンで、リンクの行き先を分けました
Instagramのプロフィールから開くリンクを変更しました。スマホなら公式LINEへ、パソコンならQRコードとLINEボタンを置いたページへ案内する形です。
ところが、端末に応じて行き先を変える処理を入れるだけでは足りませんでした。サイトを配信する側が、一度返した転送先を保存して使い回していたんです。実際に試すと、スマホで開いても、パソコン向けのページへ転送されることが分かりました。
リンクは開きます。転送もされています。でも、その端末に合った場所へ着いていません。行き先を振り分けるコードだけを見ても、以前の転送先が使い回されていることには気づけません。
AIは、転送先を使い回さない設定と、端末によって転送先が変わることを配信側に伝える設定を加えました。端末の種類を伝える情報を5種類切り替えて試し、それぞれ正しい行き先へ転送されることを確認しています。
9月5日(土)—— 相談フォームへ、サービス名を引き継ぐ形にしました
この法人向けサイトでも、サービスページから相談フォームへ進む道筋を整えました。フォームでは、サービス名に合った相談種別が最初から選ばれるようにしました。スマホには固定の案内バーを置きました。この変更の効果を判断するのは9月19日以降としています。設置しただけでは、相談につながったかどうかは分からないからです。
9月6日(日)—— この週報を、僕が書き手だと分かる文章に直しました
公開済みの週報に、担当ごとにAIへ付けた内部の呼び名が出ていました。僕には分かっても、初めて読むあなたには、誰のことか分からない名前です。僕は、記事から外すように頼みました。
もうひとつ気になったのが、書き手です。AIが「無料です」と報告した出来事を、見出しでもそのまま言い切っていました。それでは、僕ではなくAIが自分の体験を話しているように読めます。
この書き方だと『AIが書き手』ですよね。けんちろとして書いてください。
材料の中にある呼び名や報告文を、そのまま記事へ持ち込んでいたのが問題でした。出来事を間違えずに写しても、誰が言ったのかが抜ければ、別の話になってしまいます。
AIは、公開済みの週報2本から内部の呼び名を外し、「事務のAI」「集客側のAI」のように役割で書き直しました。タイトルと見出しは僕の視点へ直し、アイキャッチも作り直しています。公開後はサイト全体の文章を取得し、呼び名が残っていないことを確かめました。
再発を防ぐため、内部の呼び名を拾う機械検査を追加しました。書き手の視点は、その検査だけでは判定できません。そこで、原稿作成と推敲の指示に、AIがしたことはAIを主語にし、僕が判断したことは僕を主語にすると書き足しています。
9月7日(月)—— 見直しが要らない週にも、AIが起きていました
手順書を整理するための定期点検で、AIを呼び出す条件が、意図したものになっていませんでした。「20KBを超える手順書が3本以上あったら見直す」という条件です。ところが、20KBを超える手順書は、普段から12本ありました。
これでは、何も変わっていない週も毎回条件に当てはまります。必要な週だけ呼び出すつもりが、毎週呼び出す形になっていました。記録では、この見直しに使うAIの使用量は1回約9.7ドル相当でした。
処理自体は失敗していなかったので、問題を見落としやすい状態でした。決められた条件どおり、きちんと動いています。コードのすぐ上のコメントには「毎週鳴らさないこと」と書いてあるのに、実際の条件がそうなっていませんでした。
AIは、合計の本数で呼び出す形をやめ、前回から悪化したときだけ呼び出すように直しました。新しく20KBを超えた手順書や、前回より5KB以上増えた手順書を拾う形です。普段から長いというだけで、同じ見直しを繰り返さないようにしました。
追記を重ねる記録用の文書も、呼び出しの判定から外しました。ただし、点検の一覧には残しています。記録は追記するほど長くなります。それだけでAIを呼び出す必要はありませんが、点検の際には確認できるようにしています。
「動いているつもり」がいちばん怖いという記事では、止まった処理を見つける話を書きました。今回は反対で、動かなくてよいときにも動いていた話です。エラーが出ないから大丈夫、とは言えませんでした。
9月7日(月)—— LINEの本文だけ届いても、返信はできませんでした
僕がLINEの返信も任せたいと頼んだところ、受信通知に足りないものが分かりました。届いていたのは本文500字だけ。返信するには、相手を指定するIDも必要でした。
本文は読めるのに、システムから返信相手を指定できない。内容の確認はできても、返信には情報が足りませんでした。返信案の作成から送信までつなごうとして、この不足に気づきました。
AIは通知に、表示名と返信先を指定するIDを加えました。受け取る側が読み取れるよう、項目名と並び方も揃えています。通知を送る場所の設定も済ませ、実際に届いたメッセージで、表示名が取れることを確認しました。受信の振り分けは4件で確かめています。
ただし、届いたものすべてに返信案を作るわけではありません。メニューを押したときの相談には、すでに定型文で答えているものがあります。そこへAIがさらに返信を考えると、返事を重ねてしまいます。
そこで、通常のメッセージは返信案を作り、メニューからの相談は通知を載せるだけに分けました。相手が不特定多数なので、1時間に12件を超えたらAIを呼び出さない条件も入れています。
送信の処理には承認が必要です。承認の指定がなければ、文面を提示するところで止まります。この日の実測は受信と振り分けまでで、送信はまだ試していません。送信の処理は用意しましたが、実際に送れるかの確認はこれからです。
9月10日(木)—— 僕が返信したあとは、記録する仕事を頼みました
この日のDiscordには、僕からこんな依頼が残っています。
返信は僕がしといたからもう確定案件として、カレンダーとNotionに入れといて
僕が返事をしたので、AIに同じ返事を作ってほしいわけではありません。頼んだのは、返信のあとに必要な予定と案件の登録です。返信は僕が済ませ、記録をAIに任せました。
今週のやり取りには、「資料に入れて」「送信して」「取消」といった短い指示も残っています。撮影依頼書の受領返信や納品連絡をメールで送った記録もあります。Slackでの投稿も記録されています。
ただし、カレンダーとNotionへの登録について、この週報の材料で確認できるのは僕が依頼したところまでです。登録結果を読み直した記録はありません。そのため、「登録まで終わりました」とは書けません。
LINEは受信を確認したところまで。カレンダーとNotionへの登録は、僕が依頼したところまで。確認できた範囲をそのまま残します。AIへ任せる仕事が増えるほど、この区別が必要になります。
1週間やってみて
今週の数字をまとめると、こうです。
- 定期処理からのAI起動は152回。写真を扱う処理、返信、確認などの記録が残りました。
- AIを使わない予約カレンダーの公開チェックは110回、実際の更新は26回でした。
- Notionの過去記事は9本を修復。表やコードを、そのまま読める形へ直しました。
- LINEは、受信した内容から返信案を作るところまで仕組みをつなぎました。受信の振り分けは4件で確認しました。
今週いちばんの学びは、何をもって「できた」とするかを、仕事の途中で曖昧にしないことです。Notionに本文が入っても、表として読めなければ直す。LINEの本文が届いても、返信相手が分からなければ情報を足す。AIが条件どおりに動いていても、その条件でよいかを見直す。
そして、僕が返信を済ませたら、AIへ渡すのはその続きです。任せる範囲を広げることと、どこまで終わったかを確かめることを、セットで続けます。
任せた仕事の、どこを確かめるか
- 書き込んだ先で、そのまま読める表示になっているか。原稿の中身だけでなく、表やコードの表示まで見る。
- 次の処理に必要な情報が渡っているか。LINEなら本文だけでなく、返信相手を指定できることまで確かめる。
- 依頼・実装・実測を混ぜない。受信を確かめた段階なら、送信も確かめたとは書かない。
この話、他人事ではないと思われたら
AIへ任せたい仕事があるものの、どこで確認すればよいか迷っている方へ。業務の整理や小規模な自動化については、AI・DX伴走支援をご覧ください。

