大阪のAI活用・実践サポート
こんにちは、けんちろです。今週、定期処理からAIが起動した回数は151回でした。Discordでのやり取りやメールの確認をしながら、僕は写真の新サービスの方針を資料に残すことや、取引先への返信下書きをAIに頼んでいました。
資料の更新は承認しましたが、社外への送信とは分けました。撮影の返信案では、対応できることと、予定はまだ確保していないことを、同じ下書きに入れるよう頼みました。任せるときの条件を、具体的に伝えた週でした。
そして週の終わりには、「相手はNotionを見られないので、本文に書いて、添付も直接渡して」と伝えています。AIに仕事を頼んでいても、最後に読むのは人です。今週は、相手が読める形で渡すところまで、指示に入れました。
まず数字から
記録に残っているのは、定期処理からAIが起動した回数です。僕が話しかけた回数ではありません。試運転も除いています。
- AIの起動は151回。Discordの返信処理が44回、共有記録の確認が28回、メールの確認が27回、Slackの確認が15回でした。
- 予約カレンダーの公開チェックは105回。実際に更新したのは21回です。ここはAIを使わないスクリプトの実績です。
- 日次バックアップの実行は8回、成功は7回。実行した回数と、成功した回数を分けて見ています。
AIの起動回数をモデル別に見ると、69回、35回、35回、12回でした。これも、仕事を終えた件数ではありません。台帳が数えているのは起動なので、そのまま成果としては数えません。
カレンダーも同じです。何度も確認していますが、毎回書き換えているわけではありません。確認した回数と、実際に変えた回数を分けると、何を数えた数字なのかが分かります。今週の週報でも、この違いを分けて書きます。
9月26日（土）—— 資料を直す許可と、送る許可を分けました
この日、僕は写真の新サービスについて、資料更新を承認しました。カメラマンとモデルが登録し、ポートフォリオを作る。共作した作品を、お互いのポートフォリオに載せられる。そういう設計を、資料へ残すための依頼です。
フォロー、いいね、コメントの機能を設ける一方で、DM機能は設けない。利用者同士の連絡には、それぞれのSNSを使う。主な対象はポートレートですが、それ以外の写真やコスプレ、自撮りも禁止しない。作品をダウンロードするための機能は提供しない。僕が決めた内容を、資料へ反映するよう頼みました。
ただ、「資料を更新して」で終わりにはしていません。書き込む場所を指定し、実際の資料と元の発言を照らし合わせることも頼みました。重複や古い記述を整理してから反映し、書いたあとに読み戻して確かめるところまでです。
さらに、更新待ちの項目は、資料の更新に成功してから外すよう頼みました。権限が足りなければ、反映済みとして扱わず、原因を報告してほしいと書きました。「直そうとした」と「直った」が混ざらないようにするための指示です。
最後に、承認したのは資料の更新だけだと明記しました。メール、Slack、LINEの送信承認ではありません。資料を書く仕事と、その内容を外へ届ける仕事は、ここで区切りました。この日の記録に残っているのは更新の承認です。承認の記録だけでは、資料への反映まで終わったとは言えません。
資料更新を任せるときの決めごと
書き込む場所、照合する発言、読み戻すところまで伝える。成功するまでは更新待ちから外さない。資料更新の許可に、社外への送信は含めない。今回の依頼には、ここまで書きました。
9月27日（日）—— 「いいね」を誰に見せるか、資料に残すよう頼みました
翌日は、新サービスの「いいね」について資料更新を承認しました。作品へのいいね数を、ほかの利用者には表示しない。作品の所有者だけが、誰からいいねを受けたか確認できる。そういう仕様です。
「いいね機能があります」とだけ書くと、数が誰にでも見えるのか、作者だけが見られるのかは伝わりません。今回、資料に残すよう頼んだのは、機能の名前ではなく、誰に何を見せるかでした。
この仕様は今後変更する可能性がある、とも添えました。いま決めた内容を残すことと、将来ずっと変えないことは別です。資料を更新する依頼でも、その区別を残しました。
この日も、実際の資料と出典を確かめ、反映後に読み戻すよう頼んでいます。サービスの機能が増えるたびに、資料の言葉も具体的にしていく。今週の依頼を並べると、そこがよく見えます。
9月28日（月）—— 起動の比較と、棚卸しの繰り返しを調べる処理が直りました
この日の作業記録には、起動を比較する処理と、同じ棚卸しの繰り返しを検知する処理を修復したことが残っています。週次の監査も記録されました。
AIを何回呼んだかだけでなく、起動を比較する処理や、同じ棚卸しを繰り返していないか調べる処理も、運用の中にあります。その処理自体に修復が必要になっていました。
ただ、記録には、どんな結果が誤っていたのか、なぜそれまで気づけなかったのかという詳しい説明はありません。ここを想像で埋めると、別の失敗談を作ってしまいます。記録から分かるのは、起動を比較する処理と、棚卸しの繰り返しを検知する処理が修復されたこと。それに、週次監査の記録が残ったことです。
見張りを作れば、そのままずっと正しく働くとは限りません。今週は、見張る側の処理も修復の対象になりました。自動化の見張りについては、「動いているつもり」がいちばん怖いでも扱っています。
9月29日（火）—— 研修を比べるとき、料金以外にも目を向けました
集客を担当するAIは、海外マーケティングの研究を進めていました。この日の題材は、「研修は料金だけでなく、仕事・時間・支援の範囲で比べる」です。
AIが情報を集め、分析し、最終編集を行いました。Notionに載せた本文を読み戻し、検証したことも作業記録に残っています。調べたものを保存するだけでなく、掲載先の本文まで確かめています。
比べる項目は、料金、仕事、時間、支援の範囲です。研修を検討する人が、自分の仕事と照らし合わせて考えられる題材でした。
週の頭の研究では、見本に「自分の作業」と支援の範囲を添えることも扱っていました。今週の研究は、何を見せるかと、どこまで支援するかを続けて取り上げています。
ここで残っているのは、研究と記事の作成、掲載した本文の検証です。研修を受けた人の成果が出た、という記録ではありません。研究で得た材料と、実際の仕事で確かめた結果は分けて読みます。
9月30日（水）—— 申請を出したことと、結果が出たことを分けました
この日は、新サービスに関する申請について、資料更新を承認しました。僕がe-Govアプリから申請を提出したことを残す依頼です。元になったのは、前日の「とりあえず申請しときました」という発言でした。
資料へ残す内容には、申請の種類や審査結果は未確定という点も含めています。提出したことは書けます。でも、登録や届出がどのように扱われたのか、審査がどうなったのかまでは、この記録から決められません。
申請という言葉のあとに、つい「手続きが済んだ」と続けたくなります。でも、今回の依頼ではそこを分けました。AIに資料を直してもらうときも、提出した事実と、まだ決まっていないことを一緒に伝えています。
資料の更新を承認するときも、まだ確定していない部分は、そのまま残すよう伝えました。資料を読んで「結果まで出た」と受け取られないようにするためです。資料をきれいにまとめることより、いまどこまで進んだかが分かることを優先した依頼でした。
10月1日（木）—— 「対応できます」と「確保しました」を分けて下書きにしました
この日は、撮影についての返信メールを下書きにするよう頼みました。カメラマンの予定が空いていて、対応可能です。そのことを、まず返信へ入れるよう頼みました。
でも、最後にはこう書いています。
まだスケジュール確保はしておりません、OKの場合は確定連絡をください
空いていることと、確保したことは違います。対応できると伝えながら、まだ確保していないことも同じ返信に入れるようにしました。
下書きには、概算の見積もりと交通費の扱いも入れるよう頼んでいます。集合写真は、かっちりした形なのか、ラフに集まる形なのか。見積書が必要かどうか。返事をするだけでなく、相手に確かめたいことも具体的に伝えました。
「いい感じに返信して」ではありません。僕が伝えたいことと、まだ相手に確認したいことを並べてから、AIへ下書きを頼んでいます。その後、Discordには僕の送信指示があり、社外へ出た連絡の記録には見積もりのメールが残っています。
別の連絡では、撮影データを送るための本文も僕がDiscordへ渡しました。社外の連絡記録には、納品の連絡が残っています。同じ日に、税理士向けの会計資料を、検証済みのZIPを添えて送った記録もありました。
ただし、この記録だけでは、今週送った連絡を僕が毎回すべて確認したとは言えません。ここで扱っているのは、僕の下書き依頼や送信指示と、実際に外へ出た連絡が記録されている場面です。AIにどこまで任せているかという全体像は、自動化の全体像にまとめています。
10月1日（木）—— AIで知った候補を、サイトで確かめることを研究しました
集客側のAIが、この日にまとめた研究の題名は、「AIで候補を知っても、依頼先はサイトで確かめる」でした。こちらも、情報収集、分析、最終編集を行い、Notionに載せた本文を読み戻して検証した記録があります。
火曜の研究では、研修を比べる項目を取り上げました。この日は、AIで候補を知ったあとに、依頼先をどこで確かめるかを取り上げています。AIの紹介と、依頼する相手の確認を分けた題材になっています。
返信下書きでは、対応できることと確定したことを分けていました。研究では、候補を知ることと依頼先を確かめることを分けています。今週の記録を読むと、次へ進む前に何を確かめるかという話が、仕事と研究の両方にありました。
10月2日（金）—— 相手がNotionを見られないなら、本文と添付で渡すよう頼みました
この日、僕はカメラマンへの連絡について、こう伝えました。
全て本文に書いて添付ファイルも直接貼るようにしてください。
理由は、相手がNotionを見られないからです。僕の手元で情報がまとまっていても、そこを相手が開けるとは限りません。そこで、本文に内容を書き、添付ファイルも直接渡すよう指示しました。
AIに文章を整えてもらっても、相手が資料を開けなければ伝わりません。受け取る相手が読める形にするために、本文に書くことと、ファイルを直接添付することまで伝えました。
この日の社外連絡には、撮影の連絡や参考資料の送付が残っています。ただ、送信記録の見出しだけでは、メール本文と添付の全部を読み直したことにはなりません。本文と直接添付で渡すよう頼んだことと、メールが送られた記録は、分けて書いておきます。
10月2日（金）—— 新機能の確認を加え、導入処理の不具合も直しました
この日は、Claudeのリリースも毎週土曜に確認し、仕事に役立つものだけ知らせるよう変更した記録が残っています。OpenAI版と処理を共通化しています。
その作業では、定期処理をまとめて導入するときの不具合も直しています。すでにリンクされている設定があると、導入処理が途中で止まっていました。記録に発見のきっかけや検知が遅れた理由はありませんが、止まった箇所を修復したことは残っています。
連絡を任せるときの決めごと
対応できることと、確定したことを分けて書く。相手が開けない資料は、本文と添付で渡すよう指示する。今週、僕がAIへ伝えたのは、文章の言い回しよりも、この具体的な条件でした。
1週間やってみて
AIの起動は151回。AIを使わない予約カレンダーの公開チェックは105回、更新は21回。日次バックアップは8回実行され、成功は7回でした。回数を並べるだけでなく、何を数えているかを添えると、運用の様子が見えてきます。
資料更新では、実際の資料と出典を確かめ、書いたあとに読み戻すところまで頼みました。申請は提出と結果を分け、撮影の返信は対応可能と予定確保を分けました。相手が資料を開けないと分かれば、本文と添付で渡すよう指示しました。
資料には、まだ確定していないことも残す。連絡には、予定を確保していないことも書く。今週は、次に読む人が困らないよう、AIに任せるときの条件を具体的に伝えました。資料を読む人には、何が確定し、何が未確定かを残す。連絡を受け取る人には、読める場所へ内容を置く。そのための条件は、僕が具体的に伝えます。
起動回数が多いことと、仕事が終わったことは同じではありません。更新を承認した記録、社外へ送った記録、修復した記録。それぞれを分けて読むと、任せた仕事がどこまで進んだかを、落ち着いて見られます。今週は、何を任せ、どこまで進んだのかを、言葉にした週でした。
この話、他人事ではないと思われたら
資料更新や返信下書きを、どこまでAIに任せるか。あなたの仕事で必要な確認と、相手への渡し方を考える支援は、AI・DX伴走支援でご案内しています。
