同じプロンプトを何度も書きたくないので、AIとのやりとりを棚卸しする仕組み作った
LayerX のエンジニアが、AI コーディングにおけるプロンプトの重複をログ分析で可視化し、自動化可能なスキルやコマンドへ変換する実用的なワークフローを紹介している。
キーポイント
プロンプトの棚卸しアプローチ
人間の記憶に頼らず、AI とのやり取りログを「Fact Base」として収集・分析することで、繰り返しのパターンを客観的に特定する手法。
自動化優先順位の決定基準
集計結果に基づき、「何を何回繰り返しているか」「どれを先に自動化すべきか」をデータドリブンで判断し、リソース配分を最適化する。
スキル・コマンド・スケジュールへの変換
発見された重複作業を、再利用可能な「Skill（スキル）」、「Command（コマンド）」、または「Schedule（スケジュール）」として構造化し、生産性を向上させる。
AI プロンプトの自動化棚卸しフロー
AIへの指示をprompts.jsonlに保存し、Scheduleで定期的に棚卸しを実行してKVS（キーバリューストア）に記録する仕組みが構築された。
通知とスキル化による効率向上
棚卸し結果はSlackで通知され、再利用可能なプロンプトはSkillやCommandとして再定義されることで、同じ指示の繰り返し入力を防止する。
人間による最終判断の重要性
自動化は候補の発見までとし、Skill や Command 化の決定権は人間に委ねることで、無秩序なルール増加を防いでいます。
2 つの検出アプローチの併用
会話中の即時検出（A）と日次のログ分析による検出（B）を組み合わせることで、取りこぼしを最小限に抑えています。
影響分析・編集コメントを表示
影響分析
この記事は、AI ツールを日常的に利用するエンジニアにとって、プロンプト管理の課題解決に向けた具体的な実装アプローチを示しています。大規模なログ分析と構造化による自動化は、組織全体での AI リテラシー向上や開発フローの標準化に寄与する可能性が高く、現場レベルで即座に適用可能な実践的な知見です。
編集コメント
「AI を使う側が、使い方を振り返る」というメタ的な視点が非常に新鮮で、多くのエンジニアの共感を呼ぶ内容です。ログ分析という地味なアプローチから、生産性向上の突破口を見出す姿勢は参考になります。
imageアイキャッチ
はじめに
こんにちは。バクラク申請・経費精算の開発をしている yohei です。
最近、自宅寿司にハマっており寿司アカデミーに通うかほんの少し迷ってます。
近ごろはもっぱら AI を使ってコーディングしているのですが、同じような指示を書いてるな〜と思うことありませんか？**
PR を作って、レビューコメントを確認して、CI 失敗を直して、インシデント調査をして、QA 観点を作ってなどなどです。
毎回同じ前提や手順をプロンプトとして入力していて「無駄じゃね…」と感じるようになってきました。でも、思っているだけだと実際どうなのかはわかりません。
- 何を何回繰り返しているのか
- どれを先に自動化すべきか
- すでに自動化できているものは何か
なので、人間の記憶ではなく Fact Base にログから見つける**ことにしました！
この記事では、AI へのプロンプトログを集計し、繰り返し作業を見つけて、Skill / Command / Schedule に変えていった話を書いていきます。
どう作ったか
やっていることはとってもシンプルです。
AI への指示
prompts.jsonl
Schedule で棚卸し
KVS に記録
Slack 通知
Skill / Command / Schedule 化
自動化しているのは候補を見つけるところまでです。Skill や Command にするかどうかは人間が決めます。勝手にルールや Skill が増えると危ないので、最後は人間が見る形にしています。
必ず JSON 形式で返してください。translation フィールドのみ。他のフィールド (technical_terms 等) は一切追加しないこと — 余計なフィールドを書こうとして本文翻訳がトークン上限で打ち切られる事故を防ぐため:
{"translation": "翻訳全文"}
翻訳全文
翻訳全文
ステップ 1: プロンプトログの読み込み
~/.claude/logs/prompts.jsonl を読み、直近 7 日間のプロンプトを取得します。
ステップ 2: 自動生成プロンプトの除外
以下に該当するプロンプトは、スケジュール/タスク/スキルによる自動生成のため除外します:
#TASKで始まるもの- スケジュール名や slug が含まれるもの
- 明らかにテンプレート的な長文プロンプト（手順番号付きで 100 行超など）
- この定期棚卸しを実行するためのプロンプト（自己言及の除外）
ステップ 3: パターン分析
残ったユーザー手動プロンプトを意味的にグルーピングします。
同じ意図を持つ異なる言い回しも同一パターンとして扱います。
3 回以上繰り返されているパターンを抽出します。
ステップ 4: KVS への記録
検出したパターンを kvs_set で記録します。既存のキーは count をインクリメントします。
ステップ 5: 制度化候補の報告
count >= 3 のパターンがあれば Slack で報告します:
a. パターン名、count、具体例を投稿する
b. a のスレッドに「そのパターンを Skill/Command/Hook として作るためのプロンプト」を投稿する。
ユーザーはこのプロンプトをベースに仕組みを作る
ステップ 6: 古いエントリの削除
count が 1 で last_seen が 30 日以上前のエントリは自動削除します。
ここで気をつけていることが 2 つあります。
1 つ目は、完全一致で見ないことです。次の指示は文面が違っても同じ作業です。LLM に「同じ意図の異なる言い回しは同じパターン」と伝えてまとめさせます。
PR 作って
commit して push して PR 作成して
修正を commit して、PR まで出して
2 つ目に通知は二段構えにすることです。候補を通知するだけだと、人間は怠惰なので通知を見ただけで放置してしまいがちです。なので通知スレッドにその仕組みを作るためのプロンプトも添付させています。人間は内容を見て、よければそのまま使えます。候補を見つけて終わりにしないための工夫です。**
Slack 通知以外にも Shepherd には Question 機能があり、Shepherd 上で作成可否を行うこともできます。
※Shepherd で bot 投稿をするときに投稿者編集できるのでこの時期ハマっていたメンズナックルになってます
実際の動き
KVS に溜まった実レコードで、commit, push, PR 作成対応のパターンです。
必ず JSON 形式で返してください。translation フィールドのみ。他のフィールド (technical_terms 等) は一切追加しないこと — 余計なフィールドを書こうとして本文翻訳がトークン上限で打ち切られる事故を防ぐため:
{"translation": "翻訳全文"}
翻訳全文
examples を見ると、3/12 は都度命令していましたが、3/13 からは /ship Skill を使っていることがわかります。Skill は自動で呼ばれていますが、PR 作成などはよく使うので覚えています。
PR 作成後も CI 監視や AI レビューの指摘の修正も繰り返し行っていたため、autonomous-pr-workflow という Skill を作成し、ship 実行後に autonomous-pr-workflow を行うようにしました。
これにより実装完了後は /ship を実行するだけでレビュー可能な状態まで持っていけます。ClaudeCode/Codex にも同様の機能がありますが、PR タイトルにチケット番号付与やプッシュ前にローカルでレビューを実行するなどカスタマイズできることができます。また、その後の繰り返し作業も検知され Skill の肉付けにも使っています。
実際に拾えた繰り返しと、その後どうしたかの例です。
拾えた繰り返し
累計回数
その後
commit / push / PR作成
94回
/ship
AIレビューコメントの確認・対応
92回
review 対応 Skill（/fix-pr など）
CI・lint 失敗の修正
76回
autonomous-pr-workflow（CI が通るまで自動追従）
QA 観点作成
21回
/create-qa-checklist
いきなり完璧な自動化は狙っていません。まずは回数が多く、手順が安定しているものから取り込みます。今ある Skill 外で繰り返し実行しているものに関しては、新規で作る，既存の Skill に取り込むなど判断し育てています。
効果
2026 年 6 月時点の実データです。
- 拾えたパターン総数：29 件
- 累計回数：691 回
- Skill / Command / Schedule 化済み：22 件 / 29 件（76%）
- 仕組み化済みパターンの累計回数：652 回
この数字が表すのは手入力の削減回数ではなく、同じ作業パターンが発生した回数です。
効果が大きかったのは、AI 活用の改善を「思いつき」ではなく、実際に繰り返されている Fact(実数) から始められるようになったことです。
以前は「これ、よく頼んでいる気がする」という感覚で Skill や Command を作っていました。ログを取るようにしてからは、何を何回頼んでいるのか、どの作業が繰り返されているのかを見ながら判断できるようになりました。
ログを取るようになってからは、次に見るべきものが変わりました。
- 頻度が高く、手順が安定しているものは Skill / Command / Schedule にする
- 繰り返されていても、判断が重いものは自動化しない
- 作ったあとも、使われ方を見て Description や Skill を直す
- 個人で便利だったものを、チームに共有できる形にする
Shepherd には Skill を共有する機能もあります 🫶
AI への指示も、コードと同じように観測して、リファクタリング (改善) して、再利用しやすい形にしていく対象になりました。これが一番大きな効果でした。
追加で改善していること
この仕組みは作って終わりではありません。ログを見れば繰り返しは拾えますが、拾えたものがすべて新しい自動化候補とは限りません。
自動化済みのものを再提案しない
今いちばん困っているのは、すでに Skill や Command として実行している作業まで「自動化候補」として提案されることです。
たとえば /ship を何度も実行していると、ログ上は「PR 作成系の作業が繰り返されている」と見えます。これは正しいのですが、すでに Skill 化済みなので、新しく作るべき候補ではないです。
つまり、ログ上の繰り返しには 2 種類あります。
- まだ手順化されていない繰り返し
- すでに Skill / Command / Schedule として使われている繰り返し
前者は新しい自動化候補です。後者は、再提案するのではなく、使われ続けているログとして扱いたいです。今は、既存の Skill 名や Command 名、Schedule 由来のプロンプトを除外条件に入れたり、KVS 側に「対応済み」の状態を持たせたりして、提案のノイズを減らしています。
Skill 自体も改善対象にする
Skill 化して終わりではなく、Skill が呼ばれない、Skill 実行後に同じプロンプトを書いていることがあります。たとえば、Skill 実行後に毎回「Notion にも書いて」「Slack にも通知して」「CI が通るまで見て」「もう少しレビュー観点を足して」と頼んでいるなら、それは Skill 側の手順や完了条件を更新するチャンスかもしれません。
改善対象になるのは、たとえば次のようなものです。
- プロンプトから AI が見つけやすい説明になっているか（適切な長さか）
- 毎回追加で頼んでいる作業が抜けていないか
- どこまでやったら完了かが曖昧ではないか
- 人間が次に判断しやすい形で報告できているか
つまりログを見る目的は、新しい Skill を増やすことだけではありません。すでにある Skill が、実際の使われ方に合っているかを見直すことも含まれます。
Skill もコードと同じで、一度作って終わりではなく、使いながらリファクタリング/改善していくものだと考えています。
やってみて分かったこと
やっていることは、スクラムの経験主義に近いです。
AI の使い方も、見えていないと直せません。まずログで見えるようにし、定期的に棚卸しし、繰り返し出てくるものを小さく Skill / Command / Schedule に変えていく。
透明性・検査・適応を、AI への頼みごとにも当てはめている感覚です。AI が入ると、試して、見て、直すまでの単位がどんどん小さくなります。だからこそ、AI の使い方自体もログを見ながら小さく改善していくのが大事だと思っています。
- 繰り返しプロンプトは自動化候補
- 完全一致ではなく意味でまとめる必要がある。LLM（大規模言語モデル）にそのまま任せるだけでも実用になる
- 候補を拾うところは自動化してよいが、Skill 化・Command 化は人間が判断する
- 通知に「作るためのプロンプト」を添付すると、候補が流れずに Skill 化まで進む
- 効果測定は回数の合計より「指示がどう短くなったか」に現れる
- プロンプトもリファクタリング対象になる
おわりに
AI を使うほど、プロンプトを書く量は増えてきます。同じプロンプトを何度も書いているなら、それは自動化候補になります。
まずはログを取りましょう！**
何を何回頼んでるのか Fact（事実）を把握し、改善を行いましょう。
これからも Factbase に改善を続けていきます！🚀
原文を表示
はじめに
こんにちは。バクラク申請・経費精算の開発をしているyoheiです。
最近、自宅寿司にハマっており寿司アカデミーに通うかほんの少し迷ってます。
近ごろはもっぱらAIを使ってコーディングしているのですが、同じような指示を書いてるな〜と思うことありませんか？**
PRを作って、レビューコメントを確認して、CI失敗を直して、インシデント調査をして、QA観点を作ってなどなどです。
毎回同じ前提や手順をプロンプトとして入力していて「無駄じゃね…」と感じるようになってきました。でも、思っているだけだと実際どうなのかはわかりません。
- 何を何回繰り返しているのか
- どれを先に自動化すべきか
- すでに自動化できているものは何か
なので、人間の記憶ではなくFact Baseにログから見つける**ことにしました！
この記事では、AIへのプロンプトログを集計し、繰り返し作業を見つけて、Skill / Command / Schedule に変えていった話を書いていきます。
どう作ったか
やっていることはとってもシンプルです。
AIへの指示prompts.jsonlScheduleで棚卸しKVSに記録Slack通知Skill / Command / Schedule化自動化しているのは候補を見つけるところまでです。SkillやCommandにするかどうかは人間が決めます。勝手にルールやSkillが増えると危ないので、最後は人間が見る形にしています。
拾い方は2つあります。
系統
タイミング
仕組み
A: 会話中の気づき
AIとの対話中
CLAUDE.mdのルールに従い、AI自身が「同じ指示が繰り返された」と気づいたらKVSに記録する
B: 日次の棚卸し
毎日定時
Hookで貯めたプロンプトログをLLMが分析し、KVSを更新して候補を通知する
Aはその場で拾える代わりに取りこぼします。Bは日次なので遅れますが、日をまたいで散らばった繰り返しも拾えます。両方あると、片方だけよりだいぶ見落としが減ります。
LayerXでは、AIエージェントが社内ツールに安全に接続し、Scheduleなどで定期実行できる基盤としてShepherdが使われています。この仕組みでもShepherdのKVS・Schedule・Slack通知を使っていますが、ログ置き場・cron・KVS・チャット通知が揃えば同じものは作れます。**
Shepherdなしではもう開発できません。めちゃくちゃ便利です🫶
Sherphedについてはこちらの記事を参照してください。
Claude Codeでの実装
ここではClaudeCodeでの実装を紹介します。
1. Hookで全プロンプトをログに残す
UserPromptSubmit Hookでプロンプトを1行JSONとして追記するだけです。
※フィルタはここではやりません（分析側に寄せる）。
#!/bin/bash
# 全プロンプトをログに記録（フィルタはスケジュール側で実施）
INPUT=$(cat)
PROMPT=$(echo "$INPUT" | jq -r '.prompt // empty')
SESSION_ID=$(echo "$INPUT" | jq -r '.session_id // "unknown"')
if [ -z "$PROMPT" ] || [ ${#PROMPT} -lt 5 ]; then
exit 0
fi
LOG_DIR="$HOME/.claude/logs"
umask 077 # ログは本人のみ読める権限で作る
mkdir -p "$LOG_DIR"
echo "{\"ts\":\"$(date -u +%Y-%m-%dT%H:%M:%SZ)\",\"session\":\"$SESSION_ID\",\"prompt\":$(echo "$PROMPT" | jq -Rs .)}" >> "$LOG_DIR/prompts.jsonl"
exit 0登録は ~/.claude/settings.json に行います。
{
"hooks": {
"UserPromptSubmit": [
{
"matcher": "",
"hooks": [
{ "type": "command", "command": "~/.claude/hooks/log-prompt.sh" }
]
}
]
}
}
ひとつ注意があります。AIへの指示には顧客情報・社内情報・認証情報が混ざりえます。** プロンプトを丸ごとログに残す以上、実装する場合、最低限次の4点を先に決めてください。
- 保存先: ローカル、または社内で承認された保存先に限定する。外部サービスには送らない
- マスキング: 分析や通知に流す前に機微情報をマスクする
- 保存期間: 分析対象は直近7日のみ。ログ自体も保存期間を決めて定期削除する
- アクセス権限: ログファイルと通知先チャンネルは本人＋必要最小限に絞る
自分の環境では、ローカルのログを社内承認済みの基盤経由で本人宛てに通知する構成にしています。
2. 会話中に拾うためのルール（系統A）
グローバルCLAUDE.mdから読み込むルールはこれだけです。
同じ操作・指示が2回以上繰り返されたら:
1. KVSにパターンを記録する（key: pattern:{短い説明},
value: {"count": N, "last_seen": "YYYY-MM-DD", "examples": ["具体例"]}）
2. 既存keyはcountをインクリメントする
3. count >= 3 のパターンについて、ルール・Skill・Hookでの制度化を提案する
4. ユーザー承認なしに作成・削除してはならない3. 毎日まとめて拾うSchedule（系統B）
毎日11時に、次のプロンプトでエージェントを定期実行しています。意味的グルーピングはembeddingではなくLLMにそのままやらせています。それでも低コストで日次運用できています。
プロンプトログの定期棚卸しを行う。
## Step 1: プロンプトログの読み込み
~/.claude/logs/prompts.jsonl を読み、直近7日間のプロンプトを取得する。
## Step 2: 自動生成プロンプトの除外
以下に該当するプロンプトはスケジュール/タスク/スキルによる自動生成なので除外する:
- `#TASK` で始まるもの
- スケジュール名やslugが含まれるもの
- 明らかにテンプレート的な長文プロンプト（手順番号付きで100行超など）
- この定期棚卸しを実行するためのプロンプト（自己言及の除外）
## Step 3: パターン分析
残ったユーザー手動プロンプトを意味的にグルーピングする。
同じ意図の異なる言い回しも同一パターンとして扱う。
3回以上繰り返されているパターンを抽出する。
## Step 4: KVSへの記録
検出したパターンを kvs_set で記録する。既存keyはcountをインクリメントする。
## Step 5: 制度化候補の報告
count >= 3 のパターンがあればSlackで報告:
a. パターン名、count、具体例を投稿
b. aのスレッドに「そのパターンをSkill/Command/Hookとして作るためのプロンプト」を投稿。
ユーザーはこのプロンプトをベースに仕組みを作る
## Step 6: 古いエントリの削除
countが1で last_seen が30日以上前のエントリは自動削除する。
ここで気をつけていることが2つあります。
1つ目は、完全一致で見ない。 次の指示は文面が違っても同じ作業です。LLMに「同じ意図の異なる言い回しは同じパターン」と伝えてまとめさせます。
PR作って
commitしてpushしてPR作成して
修正をcommitして、PRまで出して2つ目に通知は二段構えにする。 候補を通知するだけだと、人間は怠惰なので通知を見ただけで放置してしまいがちです。なので通知スレッドにその仕組みを作るためのプロンプトも添付させています。人間は内容を見て、よければそのまま使える。候補を見つけて終わりにしないための工夫です。**
Slack通知以外にもShepherdにはQuestion機能があり、Shepherd上で作成可否を行うこともできます。
※Shepherdでbot投稿をするときに投稿者編集できるのでこの時期ハマっていたメンズナックルになってます
実際の動き
KVSに溜まった実レコードで、commit, push, PR作成対応のパターンです。
{
"key": "pattern:commit-push-pr-creation",
"value": {
"count": 94,
"examples": [
"okなのでcommit して push and create pr (2026-03-12)",
"/ship (2026-03-13)",
"/ship WFSB-10032 (2026-03-13)",
"/ship WFSB-10161 (2026-04-07)",
"/ship release/x.x.x に向けて (2026-04-02)",
"/ship WF-0 (2026-06-01)"
]
}
}
※実際に入力したプロンプトと日付になります。WFSB-* は開発のチケット名です
examplesを見ると、3/12は都度命令していましが、3/13からは /ship Skillを使ってることがわかります。Skillは自動で呼ばれていますがPR作成などはよく使うので覚えています。
PR作成後もCI監視やAIレビューの指摘の修正も繰り返し行っていたため、autonomous-pr-workflow というSkillを作成し、ship 実行後にautonomous-pr-workflow を行うようにしました。
これにより実装完了後は /ship を実行するだけでレビュー可能な状態まで持っていけます。
ClaudeCode/Codexにも同様の機能がありますが、PRタイトルにチケット番号付与やプッシュ前にローカルでレビューを実行するなどカスタマイズできることができます。また、その後の繰り返し作業も検知されSkillの肉付けにも使っています。
実際に拾えた繰り返しと、その後どうしたかの例です。
拾えた繰り返し
累計回数
その後
commit / push / PR作成
94回
/ship
AIレビューコメントの確認・対応
92回
review対応Skill（/fix-pr など）
CI・lint失敗の修正
76回
autonomous-pr-workflow（CIが通るまで自動追従）
QA観点作成
21回
/create-qa-checklist
いきなり完璧な自動化は狙っていません。まずは回数が多く、手順が安定しているものから取り込みます。今あるSkill外で繰り返し実行しているものに関しては、新規で作る, 既存のSkillに取り込むなど判断し育てています。
効果
2026年6月時点の実データです。
- 拾えたパターン総数: 29件
- 累計回数: 691回
- Skill / Command / Schedule化済み: 22件 / 29件（76%）
- 仕組み化済みパターンの累計回数: 652回
この数字が表すのは手入力の削減回数ではなく、同じ作業パターンが発生した回数です。
効果が大きかったのは、AI活用の改善を「思いつき」ではなく、実際に繰り返されているFact(実数)から始められるようになったことです。
以前は「これ、よく頼んでいる気がする」という感覚でSkillやCommandを作っていました。ログを取るようにしてからは、何を何回頼んでいるのか、どの作業が繰り返されているのかを見ながら判断できるようになりました。
ログを取るようにしてからは、次に見るべきものが変わりました。
- 頻度が高く、手順が安定しているものはSkill / Command / Scheduleにする
- 繰り返されていても、判断が重いものは自動化しない
- 作ったあとも、使われ方を見てDescriptionやSkillを直す
- 個人で便利だったものを、チームに共有できる形にする
ShepherdにはSkillを共有する機能もあります 🫶
AIへの指示も、コードと同じように観測して、リファクタリング(改善)して、再利用しやすい形にしていく対象になった。これが一番大きな効果でした。
追加で改善していること
この仕組みは作って終わりではありません。ログを見れば繰り返しは拾えますが、拾えたものがすべて新しい自動化候補とは限りません。
自動化済みのものを再提案しない
今いちばん困っているのは、すでにSkillやCommandとして実行している作業まで「自動化候補」として提案されることです。
たとえば /ship を何度も実行していると、ログ上は「PR作成系の作業が繰り返されている」と見えます。これは正しいのですが、すでにSkill化済みなので、新しく作るべき候補ではないです。
つまり、ログ上の繰り返しには2種類あります。
- まだ手順化されていない繰り返し
- すでにSkill / Command / Scheduleとして使われている繰り返し
前者は新しい自動化候補です。後者は、再提案するのではなく、使われ続けているログとして扱いたいです。今は、既存のSkill名やCommand名、Schedule由来のプロンプトを除外条件に入れたり、KVS側に「対応済み」の状態を持たせたりして、提案のノイズを減らしています。
Skill自体も改善対象にする
Skill化して終わりではなく、Skillが呼ばれない, Skill実行後に同じプロンプトを書いていることがあります。
たとえば、Skill実行後に毎回「Notionにも書いて」「Slackにも通知して」「CIが通るまで見て」「もう少しレビュー観点を足して」と頼んでいるなら、それはSkill側の手順や完了条件を更新するチャンスかもしれません。
改善対象になるのは、たとえば次のようなものです。
- プロンプトからAIが見つけやすい説明になっているか（適切な長さか）
- 毎回追加で頼んでいる作業が抜けていないか
- どこまでやったら完了かが曖昧ではないか
- 人間が次に判断しやすい形で報告できているか
つまりログを見る目的は、新しいSkillを増やすことだけではありません。すでにあるSkillが、実際の使われ方に合っているかを見直すことも含まれます。
Skillもコードと同じで、一度作って終わりではなく、使いながらリファクタリング/改善していくものだと考えてます。
やってみて分かったこと
やっていることは、スクラムの経験主義に近いです。
AIの使い方も、見えていないと直せません。まずログで見えるようにし、定期的に棚卸しし、繰り返し出てくるものを小さくSkill / Command / Scheduleに変えていく。
透明性・検査・適応を、AIへの頼みごとにも当てはめている感覚です。AIが入ると、試して、見て、直すまでの単位がどんどん小さくなります。だからこそ、AIの使い方自体もログを見ながら小さく改善していくのが大事だと思っています。
- 繰り返しプロンプトは自動化候補
- 完全一致ではなく意味でまとめる必要がある。LLMにそのまま任せるだけでも実用になる
- 候補を拾うところは自動化してよいが、Skill化・Command化は人間が判断する
- 通知に「作るためのプロンプト」を添付すると、候補が流れずにSkill化まで進む
- 効果測定は回数の合計より「指示がどう短くなったか」に現れる
- プロンプトもリファクタリング対象になる
おわりに
AIを使うほど、プロンプトを書く量は増えてきます。同じプロンプトを何度も書いているなら、それは自動化候補になります。
まずはログを取りましょう！**
何を何回頼んでるのかFactを把握し、改善を行いましょう。
これからもFactbaseに改善を続けていきます！🚀
関連記事
今日のまとめ
AI日報で今日の重要ニュースをまとめ読み