ミツモアAI推進G AI活用Tips50

Transcript

1. ミツモア AI活⽤ 50 Tips ⾮エンジニアが「最強のBuilder」になるまでの全記録
2. Chapter 1 Architecture & Engineering
3. ファイル管理は「マウス」を捨ててAIへ POINT ファイル操作という単純作業こそ、⾃然⾔語のコマンド⼀発で完遂させる。 BEFORE ⼤量のファイル作成やリネーム作業。GUIでカチカ チやるのは時間の無駄。 AFTER Claude Codeに「フォルダ内の全ファイルをこの 規則でリネームして」と指⽰。
4. 繰り返し作業は、まずAIにやらせて⾃動化 POINT 単純作業は従来のやり⽅をまず疑う。やる前にAIに聞く。 BEFORE 無限に繰り返す作業は、いかに効率的にコピペす るかの戦い。 AFTER ChatGPTやClaudeに「こんな仕事をしないといけ ないんだけど、効率的にできる⽅法はないです か？」ととりあえず聞く。 解決策は、AIが提案してくれる。 AIに⾔われるがまま、Pythonをインストールして 実⾏すれば速攻時短。
5. 図解は「描く」より「⽣成」 POINT 思考の整理に集中し、描画作業はAIに任せる。 BEFORE メモを⾒ながら作図ツールで箱や⽮印を並べる 「お絵かき」の時間。 めちゃくちゃ⼤変で、時間がかかる。 AFTER メモや議事録をそのまま渡して「Mermaid形式で フロー図のコードを書いて」と指⽰しレンダリン グ。
6. Dify活⽤の「⺠主化」と「安全確保」 POINT 誰でも安全‧簡単に使えるインフラを整備し、組織の⾃動化レベルを底上げする。 BEFORE 各⾃がバラバラにDify連携を⾏い、認証キーの管理 が属⼈化。 AFTER GAS × Dify連携の「共通コネクタ」をAIとペアプ ログラミングで開発‧配布。
7. 勤怠エラー通知の業務をシンプル化 POINT コーディングの前に、AIと「業務プロセスの再設計（BPR）」を⾏う。 BEFORE 複雑怪奇な勤怠ルールや関数をコードにしようと して無駄が多発。 AFTER AIに業務フローを解析させ、「そもそもこの判定 いらない」と断捨離してから実装。
8. Google検索をAPI化して「検索」を無⼈化 POINT ⼈間が検索窓を叩くのではなく、プログラムに検索させる。 BEFORE リスト作成のために⼀件ずつググってコピペする 単純作業。 AFTER Custom Search API × GAS。キーワードリストを 渡すだけでリストを作るBotを作成。
9. 「動くけど汚いスクリプト」をリファクタリング POINT 「過去の負債」をAIに返済させ、メンテナンス可能な状態を保つ。 BEFORE 過去の⾃分が書いた継ぎ接ぎだらけのGASコー ド。怖くて触れない。 AFTER コードをAIに投げ、「可読性の⾼いコードに書き 直して」と清書。⽇本語の補助テキストも付与。
10. スプレッドシートを「簡易DB」として使い倒す POINT 本格的な開発の前に、MVP（実⽤最⼩限の製品）を爆速で⽴ち上げる。 BEFORE ツールを作るのに、わざわざ本格的なDB構築をす るのは⼤掛かり。 AFTER GASとスプシを連携しまくる。AIに⼊出⼒処理を書 かせてRDB代わりに酷使する。
11. エラーログは「読む」前に「貼る」 POINT 「調査」時間をショートカットし、⼈間は「修正の判断」だけを⾏う。 BEFORE エラーログとにらめっこし、原因を推測してググ る時間のロス。 AFTER ログを思考停⽌でAIにペースト。場合によっては画 ⾯スクショも。「原因と修正案を教えて」と聞 く。
12. テストデータは「⼿作り」しない POINT ⼯数は半分のまま、⼈間では思いつかない意地悪なデータで堅牢性を⾼める。 BEFORE 動作確認⽤データ作成が⾯倒で、正常系の簡単な パターンしかテストしない。 AFTER 「異常値や境界値を含むテストデータを100件作っ て」とAIに量産させる。
13. 構造エラー修正は「探す」前に「投げる」 POINT データの「整形外科医」としてAIを使う。 BEFORE CSVのカンマずれやJSONの構⽂エラーを⽬視で探 す徒労。 AFTER エラーデータとコードなどを丸ごとAIに渡し、 「正しいフォーマットに直して」と丸投げ。
14. セルフレビューで「凡ミス」を撲滅 POINT 「もう⼀⼈の厳しい先輩エンジニア」をAIとして飼う。 BEFORE ⾃分では完璧だと思ってリリースしたら、初歩的 なセキュリティホールが発覚。 AFTER 「この設計に脆弱性や考慮漏れはある？」と意地 悪な視点でレビューさせる。
15. 複雑なデータ抽出を「⾃然⾔語」で POINT データの⺠主化。エンジニアの「割り込みタスク」をゼロにする。 BEFORE SQLが書けないメンバーが、毎回エンジニアに抽出 依頼をする。細かい修正で時間が溶ける。 AFTER 「先⽉の未対応顧客を出して」と打てば、AIがSQL を書いて実⾏する仕組みを⽤意。
16. 業務フローの可視化を丸ごとAIに POINT AIが理解しやすい形式（コード）で業務フローが保存できる。 BEFORE 業務フロー図を思い出しながらツールで1つずつブ ロックを線で結ぶ作業。 AFTER 参考資料を全てNotionAIに渡し、可視化 （Mermaid）してもらう。違っているところは訂 正して直してもらう。
17. GAS開発は「ブラウザ」で書かない POINT ⾮エンジニアこそ、AI×最新ツールで「コーディング」の時間をゼロにする。 BEFORE ブラウザ上で直接修正。バージョン管理できず、 ファイルが増えると、コードのコピペも⼀苦労。 AFTER Clasp × Claude Codeでローカル開発。バージョ ン管理もローカルに保存。
18. Difyの仕様書は完成してから逆⽣成 POINT NoCodeツールこそ、コードベース（テキスト）で管理‧⽂書化する。 BEFORE 画⾯スクショを貼って仕様書を作るのは管理不能 で、不完全。 かといって、完成したワークフローがあるのに⼿ 書きで設計図を書き起こすのは⾯倒。 AFTER DifyでワークフローのDSL（YAML）をダウンロー ドして、AIに読ませてドキュメント化。毎回同じ クオリティで書き損じも起きない。
19. エラー画⾯は「読む」のではなく「⾒せる」 POINT ⾔語化できない現象をマルチモーダル（視覚）で解決する。 BEFORE エラーログをコピペできない画⾯や、複雑なGUI挙 動の説明が⼿間。 AFTER 画⾯録画やスクショを撮り、AIに「この動きと同 じコードを書いて」と投げる。
20. 複雑な仕様書は「逆⽣成」する POINT 「実装 → ドキュメント」の順序を⾃動化し、乖離を防ぐ。 BEFORE コードは書いたが、仕様書を作る気⼒がない。な んだかんだ仕様書と実態が違う。 AFTER 実装コードをAIに渡して、「仕様書を出⼒して」 とドキュメントを逆⽣成。
21. Chapter 2 Sensory & Input
22. お客様の声（VOC）分析をAIで POINT 数値化できない「⽣の感情」をデータとして扱う。 BEFORE アンケートは選択肢などのデータしか活⽤できて いない。フリーコメントをなんとなく読み、傾向 を掴むだけ。 AFTER 回答の全データをDifyに投⼊。フリーテキストを 構造化データにして数値化したり、深いインサイ トや隠れたニーズを抽出。
23. 英語のドキュメントは「読まない」 POINT 「読む」努⼒を放棄し、AIに「読ませて聞く」ことで⾔語の壁を突破する。 BEFORE 英語ドキュメントを開いた瞬間、吐き気がしてた …。 AFTER URLをGeminiやNoteBookLMなどに貼り付け、 「この仕様の要点を教えて」と⽇本語で質問攻め にする。
24. ⾳声は「聞かない」ためにAIを使う POINT AIを情報のフィルタリング装置とし、⼈間の時間は確認だけに使う。 BEFORE ⻑い録⾳データを全部聞くのは時間がとってもか かる。でも聞き逃しは怖い。 AFTER ⽂字起こしデータをAIに渡し、「〇〇の話は何分 くらい？」と聞き、該当箇所だけをピンポイント で聞く。
25. 社内情報の「捜索‧まとめ」はNotion AIが代⾏ POINT ⼈間が探すのではなく、AIに「持ってこさせる」。 BEFORE 「あの資料どこだっけ？」とDriveやNotionを彷徨 い、時間を溶かす。（結果、⾒つからなかったり する） AFTER Notion AIに「〇〇の関連資料をまとめて」と調査 ‧集約させる。⼀旦多めに集めてもらって整理す る。
26. 判断の⾼速化。迷いや要件を「喋って」⽐較表へ POINT AIは決めてくれないが、決めるための「地図」は描いてくれる。 BEFORE ツール選定や意思決定の条件が頭の中で絡まる。 AFTER ⾳声⼊⼒で条件を伝え、「メリット‧デメリット ⽐較表にして」と整理させる。
27. キーボードに触らず「概念」を理解する POINT 対話のラリーを⾼速化し、腹落ちするまでの時間を短縮する。 BEFORE 複雑な概念を理解するために、⻑いテキストを 打って質問するのが億劫。 AFTER ⾳声対話で「要するに〇〇みたいなこと？」とた とえ話を使って確認。対話で腹落ちさせる。
28. 検索ワードがわからないなら「⾒せる」 POINT 「⾔語化できない情報」へのアクセス障壁を画像認識で突破する。 BEFORE 読み⽅のわからないロゴやエラー画⾯の前で⽴ち 尽くす。 AFTER スクショを撮ってChatGPTに送信。「これなんて 書いてある？」と聞く。
29. セミナー資料作成は「ほぼ⾃動化」 POINT ⾯倒な作業はAIに任せ、⼈間は最後の「魂（メッセージ）」を吹き込む2割に注⼒。 BEFORE スライドの構成から⽂⾔まで、⽩紙の状態から悩 む。⼀般的な⾒解なども調べる。 AFTER Geminiに投げつけて構成を作る。構成ができたら Canvasで「スライド作成して」。
30. シフト登録は「スクショ」を投げるだけ POINT アプリ間の隙間を埋めるのはAPIではなく、画像認識が⼀番早い。 BEFORE 勤怠画⾯を⾒てカレンダーに⼿動転記。 AFTER 申請完了画⾯のスクショをGeminiに渡し、「この シフトをカレンダーに⼊れて」で登録完了。
31. 集計業務はAI使って効率化→完全⾃動化 POINT AIを⼀過性の「作業者」にせず、永続的なツールの開発者として使う。 BEFORE 最初はAIが分析してくれて満⾜！！ データが上書きされたら毎回分析してってお願いし ないといけないので、AIにデータを渡して分析させ るコピペ作業が⾯倒になってきた。 AFTER AIに分析だけでなく、「この分析プロセスを⾃動 実⾏するGASコードを書いて」「スプシ構造も セットで作って」と依頼。 GASでセットアップが完了してデータが上書きさ れても常に最新の分析結果が⾒れる状態に。
32. 「これ、冷たくない？」送信前のメンタルガード POINT チームの⼼理的安全性を、AIというクッションで守る。 BEFORE テキストコミュニケーションで意図せずきつい⾔ い⽅になってしまう。 AFTER 送信前に「冷たく感じる？もっと柔らかくして」 と過去のSlackも送って、嚙み合っていない部分の 補強をして、推敲させる。
33. 読めない漢字データに「フリガナ」を⾃動付与 POINT 従来のツールでは不可能な「推測によるデータ補完」を実現。 BEFORE 漢字だけの顧客リスト。ソートも検索もできず不 便。 AIに⾳声読み上げさせても間違えまくる。 AFTER Difyをリストと連携させ、「推測してフリガナを 振って」とデータを補完させる。
34. Chapter 3 Organization & Reflection
35. 「ガイドライン」はゼロから書かない POINT ⼈間は「0→1」ではなく「1→10（確認‧修正）」に専念す る。 BEFORE ルールブック作成。⽩紙から書き始めると構成で 悩み数⽇かかる上に⾜りない、⾜りない…。 AFTER NotionAIに「⽬的」「ターゲット」「私が書きた いこと」を伝え、AIにドラフト版を作成させる。
36. アンケート未回答者メンションはAIが代⾏ POINT ⾯倒なデータ突き合わせを、⾃然⾔語だけで完結させる。 BEFORE 回答CSVと社員名簿を突き合わせ、未回答者を毎回 抽出するのが⾯倒。 AFTER NotebookLMに両⽅を⼊れて「未回答者をメン ション形式でリスト出して」と指⽰。
37. 「私って今年何した？」をAIに思い出させる POINT 「記憶」と「記録」の統合。AIをキャリアの専属書記官にする。 BEFORE 期末の評価⾯談前、1年間の記憶が曖昧でログを⾒ 返すだけで終わる。 AFTER 過去の定例の資料をNoteBookLMに読ませ、「私 の1年間の成果」をドラフトさせる。
38. 誰にも⾔えない悩みは「壁打ちAI」へ POINT ⼼理的安全性が無限⼤の相⼿と、思考の外部化を⾏う。 BEFORE 思考がまとまらないが、同僚の時間を奪うのは申 し訳ない。 AFTER ⾳声⼊⼒でモヤモヤを話し続け、AIに「整理し て」と依頼。⾃分がすっきりしなければ、解決す るまで会話に付き合ってもらう。
39. 隙間業務の「マイクロツール」を内製 POINT 欲しい道具は、探すより作る⽅が早い（かもしれない）。 BEFORE ちょっとしたテキスト加⼯がしたいだけ。イン ターネットにあるフリーソフトを使えれば楽なの に‧‧‧（粛々と⼿打ち）。 AFTER Claudeに「これをHTMLファイルで作って」と頼 み即席開発。
40. 定例資料の作成⼯数を「半分」に POINT 「報告のための資料作り」という⾮⽣産的な時間を削減する。 BEFORE 過去の議事録やチケットをひっくり返して報告資 料を作る苦⾏。 AFTER Notion AIが過去ログから「報告すべきトピック」 をピックアップ。私は質問に答えるだけで書き込 みまで完了。
41. 開発者ドキュメントは「読む」より「格納」する POINT ⾃分専⽤の辞書を作り、正確な情報を引き出す。 BEFORE 複数の公式ドキュメントを⾏き来して仕様確認。 まず英語だし、専⾨⽤語わからないし…。 AFTER NotebookLMに公式ドキュメントを格納して、信 頼できるRAG環境を構築。コード⽣成プロンプト も作ってもらう。
42. 業務フロー解析からの「ロジック再考」 POINT ⾃動化の前に「そもそもその業務いる？」を判定する。 BEFORE ⾮効率な業務フローをそのまま⾃動化し、複雑化 させる。 AFTER NotionAIに「今の業務はこれ。もっと効率的なフ ローない？」とヒアリング議事録を元にBPRさせ てから実装。
43. 要件定義書の更新は「修正依頼」をコピペ POINT ドキュメントメンテナンスのコストを極限まで下げる。 BEFORE Slackで仕様変更の会話をするけど、ドキュメント 更新を忘れて形骸化。変わるのに書くの？ってな える。 AFTER チャットログもNotion AIに貼り付け、「この通り 書き換えて」と指⽰。
44. ⾯接官デビューもAIとシミュレーション POINT 経験不⾜をAIという「ベテラン⼈事」が補完してくれた。 BEFORE ⾯接で何を聞けばいいか、どう評価すればいいか 不安。 AFTER レジュメから「聞くべき質問」と「評価軸」を作 らせ、AIを候補者にならせて壁打ちリハを実施。
45. Excelへの⼤量コピペ作業をAIに丸投げ POINT AIにマニュアルを読ませ、「⽂書理解」によるデータ転記を代⾏させる。 BEFORE Excelファイルに、マニュアルからたくさんの情報 をコピペしないといけない。 AFTER ClaudeCodeに「マニュアルから探して、Excel ファイルのこの部分を埋めて！」と指⽰。⽂書理 解によるデータ転記を代⾏。
46. 定性アンケートの「声」をデータ化 POINT 定性情報を定量データのように扱い、インパクトの⼤きい効率化に取り組む。 BEFORE ⾃動化したい業務に関するアンケートの⾃由記述 を1つずつ読むのは⼤変。 AFTER アンケートが届いたらDifyで分析。「現場の声」を カテゴリ分けして、⾃動化に必要な不⾜情報まで AIに書き出させる。
47. Chapter 4 The Twist - I am a Builder
48. Slack報告だけでNotionタスク完了 POINT 報告と管理の⼆度⼿間をなくし、常に最新の状態を保つ。 BEFORE Slackで「終わった」と⾔い、Notionも⼿動で Doneにする。⼆度⼿間。 AFTER Slackで「終わった」と⾔えば、Notionも⾃動で Doneになる連携を構築。
49. Googleフォームは「画⾯」で作らない POINT フォーム作成を「作業」から「デプロイ」に変える。 BEFORE GUIでポチポチ設定。必須チェック漏れ等のミスが 起きる。 AFTER 壁打ちで構成を決め、GASで⽣成。実⾏ボタン⼀ つで完成。
50. 複雑な数式‧正規表現は「解読」させる POINT ブラックボックス化した資産をホワイトボックス化する。 BEFORE 誰かの秘伝のタレ（Excel/Regex）。解読不能で触 るのが怖い。 AFTER そのまま貼り付け、「これ⽇本語で⾔うと何？」 と解説させる。
51. そのときだけ使いたいChrome拡張機能を⽣成 POINT 脳死で⼿を動かす前に博識AI様に泣きついてみるといいことがある。 BEFORE 全部ちまちま⼿作業。繰り返す作業が⾟い。 AFTER Claudeに「Chrome拡張機能でできるかも」と提 案され、ClaudeCodeでコードを⽣成し、⼀時的な 拡張機能を⾃作。
52. 「カスタム指⽰」で前提説明を省略 POINT AIとの「阿吽の呼吸」をできるだけ実現する。 BEFORE 毎回「私はこういう役割で…」と説明するのが⾯ 倒。 AFTER NotionAIのカスタム設定に事前に私の情報や属 性、嫌いな会話の流れなどを覚えさせる。
53. 効果検証⽤の「SMS」通知をGASで⾃作 POINT 「どうせできない」と悩むのをやめて、AIとエンジニアリングをやってから悩む。 BEFORE 重要な通知メールが埋もれ、開封されない。SMS とか送りたい。けど開発が必要で時間をさけな い。 AFTER Twilioの仕様をClaudeに聞き、APIをGASで叩き、 特定の条件で「SMS」を⾃動送信するインフラを 構築。
54. 電話業務も無⼈化。「オートコール」の実装 POINT 精神的苦痛を伴う業務こそ、APIとAIをつなぎ合わせてシステムに代⾏させる。 BEFORE 督促などの架電作業は精神的負担が重く、時間も 奪われる。やりたくない。 AFTER ⾃動⾳声やAIによる回答を⾏うオートコールシス テムを⾃前で実装。作る→試す→改良するを繰り 返す。
55. GASのエラー時「⾃動リトライ」ロジック POINT ⼿作業のフォローができるだけ少ない仕組みを作る。 BEFORE 何かの拍⼦で⼀瞬の通信エラーで処理が⽌まって しまう。わからないので⼿動で再実⾏。 AFTER ClaudeCodeにログを読ませ、「失敗したら5秒 待って再試⾏」というコードを書かせる。
56. 「テスト仕様書（テストケース）」の⽣成 POINT 品質の担保もAIと⾏う。 BEFORE GASが完成した！けど、使ってみたらボロボロで機 能は作ったが、使い物にならなくて破棄。 AFTER ClaudeCodeにまず仕様書を作成させる。コーディ ングと並⾏してテストケースも書かせ、品質を担 保。
57. ⾔語の壁を越える「コード翻訳」 POINT 実装⾔語の違いはもはや障壁ではない！ BEFORE Pythonの便利なコードを⾒つけたが、GASで使い たい。 AFTER ChatGPTにページのURLを送って、「このロジッ クをGASに書き換えて」と翻訳させる。
58. 問い合わせの読み取り‧回答⽅針を提案作成 POINT ちゃんと伝わりお客様の問題解決をスムーズに。 BEFORE お客様からの問い合わせを担当者が読んで、返答 ⽂章を作成する。 個⼈で捉え⽅が違ったり、読み取り間違えて誤っ た理解で返答してしまうと、お客様を困らせてし まう。 AFTER 問い合わせの受付と同時にDifyが起動して、お客様 の問い合わせや属性から情報を整理。 回答マニュアルと照合して、AIが回答⽅針の下書 きを作成。 担当者はAIの出⼒をチェックして、お客様に返信 をする。
59. 私は「エンジニア」ではない POINT AIがいれば「会社のインフラ」の壁さえも超えられる。私は「Builder」になった。 BEFORE アイデアはある。でもコードが書けないから、エ ンジニアにお願いして待つしかない。 AFTER 「やりたいこと」をAIに伝え、環境を作り、コー ドを書き、SMSや電話のインフラまで構築した。 すべて⾃分でやった。