大阪のAI活用・実践サポート
こんにちは、けんちろです。今週も撮影の仕事をしながら、DiscordでAIに依頼を出していました。返信を頼んだり、資料に入れる内容を承認したり。撮影が終わった報告も、ここに残しています。
9月12日〜19日の記録を確認すると、定期処理からAIが起動したのは102回でした。予約カレンダーの確認やバックアップには、AIを使わないプログラムが別に動いています。
今週は、けんちろワークスのサービスの見せ方を決め直しました。「やり方を教える」と「僕が構築を代行する」を分け、「教える」をサービスの中心にしました。資料を更新するときの承認や、新しいサービスを作る順番も決めました。
まずは、今週動いた処理の数字から
この期間に動いた処理の実測値です。AIの起動回数には、実際には処理しない試運転を含めていません。
- AIの起動は102回。内訳には、Discordでの返信処理54回、Slackの確認23回、メールの確認8回などがあります。
- 予約カレンダーの公開チェックは110回。実際に更新したのは26回でした。
- 日次バックアップは7回動き、7回とも成功。直近のバックアップ容量は1643.58MBです。
- 週間プランの通知は29回。予定変更に合わせて通知を貼り直したのは34回でした。
カレンダー、バックアップ、週間プランの数字は、AIを使わない処理の実績です。AIの102回とは分けて数えています。全部をAIに考えさせているわけではないんですよね。
また、AIが起動した回数と、仕事を終えた件数も別です。この数字で分かるのは、何がどれだけ動いたか。何を決めて、どこまで進んだかは、日々のやり取りと合わせて振り返ります。
9月12日（土）—— 資料の更新をリアクションで承認できるように頼みました
この日、僕はDiscordでこう頼みました。
資料に入れて
そしてこれもリアクションボタンで承認非承認を選ぶ形にして。
翌日も、資料への反映と、リアクションボタンで承認できる仕組みを頼みました。資料に何を残すかを、僕が選べるようにしたかったのです。
9月15日以降の依頼には、「資料更新提案を👍で承認しました」という文が出てきます。対象は、新しいサービスの方針やデータの受け渡し方法などです。承認した内容に加えて、反映先の資料と、もとになった僕の発言の日付も記されていました。
承認の文面には、「これは資料だけの承認です」とあります。メールやチャットを送る承認とは分けています。資料を書き換える許可が、外部へ連絡する許可まで含むことになっては困ります。
資料を更新したあとは、保存した内容を読み直して確かめるように頼んでいます。僕が承認した段階と、AIが更新を終えて内容を確認した段階は、分けて扱います。
ボタンで選べるようにする考え方は、「お客さんに入力させてはいけない」でも扱いました。今回は、僕自身が資料の更新を承認するときにも、リアクションで選ぶ形を使っています。
9月14日（月）—— データの受け渡し案を、容量を見て見送りました
取引先へデータを渡す方法を相談していたとき、僕はこう返しました。
10Gでは全然だめなのでやめときます
検討していたのは、Cloudflareの無料枠を使う案でした。必要なデータを渡すには、10GBでは足りない。そう判断し、この案は使わないことにしました。翌朝には、その決定を資料に残すことも承認しています。
無料で使えても、必要なデータを渡せなければ仕事には使えません。今回は、取引先へ渡すデータの容量を基準に、採用を見送りました。
「この用途では使わない」という判断を、資料に残すよう頼みました。
9月14日（月）—— 新しいアプリは、特定の接続方法に頼らない方針にしました
同じ日、Webアプリや新しいサービスの接続方法についても方針を変えました。NetBirdへの接続を、利用の条件にしないというものです。
VPNを経由する構成に頼らないよう、僕は「NetBird依存はやめてください」と伝えました。翌朝、その方針を資料へ反映することも承認しています。
資料に入れる内容には、対象が「Webアプリや新規サービス」であることも書かれています。「接続方法を変える」だけでは、何の話か分かりません。どのサービスについて決めたことなのかも、一緒に残します。
9月15日（火）—— 「教える」をサービスの中心にしました
けんちろワークスのサービスを、「やり方を教える」と「僕が構築を代行する」の2パターンに分ける方針を決めました。そのうえで、ホームページでは「教える」を中心に紹介します。
看板にするのは、受講者自身が作成する3回講座です。講座で手を動かすのは受講者、と決めました。
「僕に作ってほしい」という依頼なら、僕が構築を代行します。「自分で作れるようになりたい」という依頼なら、やり方を教えます。サービスを分ける際に、この違いをはっきりさせました。
講座では受講者が作り、代行では僕が仕上げたものを受け取ってもらいます。それぞれ何を頼めるのかが伝わるように案内する方針にしました。
翌朝、この方針を資料へ反映する提案も承認しました。「教える」を中心にすることと、受講者が作る講座を看板にすること。どちらも、あとで参照できるように資料へ残すよう頼みました。
9月16日（水）—— 講座を届ける企業の規模を決めました
講座の形を決めたあと、今度は届ける相手を考えました。僕は、従業員10〜20人の企業に向けた3回講座にする方針を決めました。
ここでいう人数は、会社の従業員数です。講座に同時に参加する人数を決めたわけではありません。どのくらいの規模の会社へ届けるかを決めました。
業種も見直しました。顧客情報をAIで扱う際のセキュリティ面が気になり、保険・証券代理店を営業対象から外して、別の業種にするよう指示しています。
AIで何かを作る前に、その仕事で扱う情報を見て、案内する相手を選び直しました。講座の内容だけでなく、誰に向けて案内するかも僕が判断しました。
これらの判断は、翌朝の資料更新の承認にも残っています。従業員数と業種について決めたことを、それぞれ出典とともに反映するよう頼みました。
9月16日（水）—— 新しいサービスは、ブラウザ版から始めることにしました
カメラマンとポートレートモデルをつなぐマッチングサービスも、進める方針を決めました。作る順番と、サービスでどこまで引き受けるかを整理しました。
まずブラウザ版を公開し、そのあとスマホアプリ版へ進む。この順番にしました。あわせて、カメラマンとモデルの間で行う金銭のやり取りには関与しない、と決めています。
人をつなぐサービスにすることと、お金のやり取りを引き受けることは、別の話です。今回は、サービスとしてどこまで関わるかも決めました。
翌朝、まずブラウザ版を公開することと、金銭のやり取りに関与しないことを資料に残すよう頼みました。何を作るかだけでなく、進める順番も記録してもらいます。
9月16日（水）—— 開発中のゲームは、いまの契約の範囲で進めます
開発中のゲームで使うAIについても、方針を決めました。当面は、いま使っているChatGPTのサブスクリプションの範囲で運用します。
規模が広がって収益化できたら、APIの利用を検討します。プログラムからAIを呼び出す使い方に進むかどうかは、その段階で考えることにしました。
まずは今の契約の範囲で動かす。APIを使うかどうかは、規模と収益化の状況を見て決める。道具を切り替えるタイミングも、ここで整理しました。
9月17日（木）—— 研究記事は、AIが保存先の本文まで確認しました
この日の海外マーケティング研究は、「AI講座の説明に、仕事の見本と確かめ方を添える」というテーマでした。
集客側のAIが収集・分析・最終編集を行い、Notionに保存した本文も開き直して確認しています。作業記録には、執筆から保存後の確認まで残っていました。
「書いておいて」と頼んだ文章が、あとで読む場所に保存されているか。この研究記事では、AIがそこまで確かめています。記録を見れば、作業がどこまで終わったかを確認できます。
資料の更新を承認するときも、AIには同じ確認を頼んでいます。古い記述や重複を整理して反映し、保存した内容を読み直す。反映できたことを確かめてから、対応する項目を管理用の記録から外すよう指示しています。
権限が足りずに更新できないときは、反映済みにせず原因を報告するようにも頼んでいます。僕が承認ボタンを押しただけで、資料まで直ったことにはしません。
資料を更新するときの決めごと
- 今ある記述と出典を確認する。古い内容や重複を整理してから反映します。
- 保存した本文を開いて確かめる。反映できたことを確認するまで、終わった扱いにしません。
- 更新する権限が足りなければ、反映済みにしない。何ができなかったかを報告します。
古い決めごとが残る問題は、「AIへの指示書は、足す前に実体と突き合わせる」でも扱いました。今週の資料更新でも、新しい内容を足すだけでなく、古い記述も整理するよう頼んでいます。
9月18日（金）—— Discordから返信の送信を指示しました
この日の昼、僕はDiscordで返信を送るように指示しました。その後、Slackへ実際に投稿した記録が残っています。前日にも、送信を頼んだ返信と、取り消した返信がありました。
資料更新の承認とは別に、返信案には「送信して」「取消」と伝えています。こうしたやり取りでは、文章づくりをAIに任せても、送るかどうかは僕が選んでいます。
社外への連絡には、取引先から依頼を受け取ったことを伝える返信や、到着時刻を了承したメールもありました。下書きを作った記録と、実際に送った記録を分けて確認できます。
今週を振り返るときも、送るように頼んだだけで実行済みとは数えていません。その後の投稿やメールの記録まで確かめています。
1週間やってみて
AIの起動は102回。予約カレンダーは110回確認して26回更新し、日次バックアップは7回とも成功しました。週間プランは29回通知され、予定変更に合わせた貼り直しも34回ありました。
その間に僕が決めたのは、「教える」を中心にするサービスの形や、講座を届ける相手、新しいサービスを作る順番です。資料の更新を承認したり、容量が合わない案を見送ったりもしました。
資料の更新を承認したら、その資料の更新だけを任せる。新しいサービスは、作る順番と関わる範囲を決めてから進める。振り返ると、今週の学びは「何を、どこまで任せるか」を具体的に決めることでした。起動回数だけでは見えない、僕の判断がそこにあります。
任せたあとは、保存先まで確かめる。研究記事ではAIがそこまで実行し、資料更新の依頼にも同じ手順を入れています。頼んだことと、終わったことを分けて見る。今週のやり取りにも、その大切さが表れていました。
この話、他人事ではないと思われたら
あなたの仕事で、AIに何を任せ、どこを自分で判断するか。具体的な作業から整理したい方は、AI・DX伴走支援をご覧ください。
