Share
Embed
AI活用のコスパを最大化する方法
生成AIは非常に便利ですが、実務では「無限に使える道具」ではありません。
トークン制限やリクエスト制限がある環境では、1回のやり取りでどれだけ意図を正確に伝えられるかが、そのまま成果と速度に直結します。つまり、AI活用の本質は「たくさん質問すること」ではなく、「再試行を減らす設計」にあります。
「再試行を減らす」ためにはどうしたらいいか、トークン制限やリクエスト制限を回避するにはどうしたらいいか。 そういう実務におけるテクニックの話をいたします。
Ochtum
March 19, 2026
Transcript
45 slides
-
2026 年 3 月 勉強会 AI 活用のコスパを最大化する方法
壁打ちを 減らして 出来る エンジニアになろう 対象 : AI 活用を始めたエンジニア / テックリード 2026.03.20 -
ターゲット層 ・ 使用制限に すぐ ひっかかる 人
・ 生産性を 上げろと 詰められる 人 ・トークンとか リクエストとか よく わからない 人 ・ GitHub Copilot 負けてるんじゃない?って 思ってしまった 人 そんな ことないよ\(^o^) / -
今回伝えたい こと ・コスパを 意識した AI 活用方
法 ・ 使用制限を 回避するには 再試行を 減らすには (壁打ちを 減らそう) -
まず知るべきこと AI ペアプログラマーとは AI コーディングエージェントとは 開発者と 対話しながらリアルタイムで
コード提案・レビュー・デバッグを 行う AI 。 人間の 介入を 最小限に 抑えながら、 自律的にコードを 計画 / 記述 / テスト / 編集する AI -
まず知るべきこと GitHub Copilot : AI ペアプログラマー寄りの設計 Codex/Claude : AI
コーディングエージェント寄りの 設計 → 計算方 式が 1 質問= 1 リクエスト 但し、 ブラウザ (issue などから 動かす 場合)は、 AI コーディングエージェント設計の ため、 自律的に 動く。 壁打ちで やり 取りが 多いと コストは 増えるが、 プロンプトに 無駄が あっても コストは 変わらない → 計算方 式が 1 トークン。 壁打ちで やり 取りが 多い、 プロンプトに 無駄が 多いと コストが 増えてしまう。 ※ セッションとは? 1 回接続すると 1 セッション。 チャットは セッション単位で 保存される。 最近、 こっちよりの 実力も 持ちつつある -
まず知るべきこと 生産性って なんだっけ? 作業の 効率=作業の 生産性 労働生産性
「使った 経営リソース ( 人・モノ・金)で どれだけ利益を 生んだか」を 示す お金の 指標 ( 生産性が 高い ほど、 高コスパで 儲かったと いう こと) 通常、 職場では こちらの ニュアンスで 使われる ことが 多い -
資本 資産 売上高 費用 IT 投資 マーケティング費 人件費 2 ~3
年ほど苦しい 売上高 費用 利益 IT 投資 マーケティング費 人件費 2~ 3年後 マーケティング効果 に よる 増加 負債 調達 運用 (仕組み) 利益 IT 投資により 人件費増加を抑制 IT 投資は 売上増( 仕事量) と セットで 考慮する マーケティング費は 営業活動効率化の 一種 増加した コスト まず知るべきこと -
労働 生産性が 上がると 何が 起きる? 労働分配率に よって 労働者に 利益が 還元される
労働分配率= 儲けた お金から 労働者に 分配した 割合 まず知るべきこと -
まず知るべきこと 生産を 増やす いままで 実現できなかった ことを 実現する =生産できなかった ものを
生産する マルチタスクに する =生産を 増やす 人が いない ときも 作業して もらう -
AI に 伝える 技術を 磨く (個人の
パフォーマンス向上) 伝える 力を 磨く 伝えるではなく、 伝わる 説明力を 磨くと、 AI との 壁打ちが 減る 伝える 内容は Markdown で 書く Markdown は AI が 理解しやすい 構造に なっている -
避けるべきパターン プロンプトが 簡潔すぎる 「いい 感じで 直して」では 優先順位や 対応内容が 不明確。 対応が
ぶれやすい。 ルールが 未記載 ルールや 対応手順が あるのに 伝えないと 後だし修正が 増える プロンプトが 長すぎる (まとめて 依頼しすぎる) AI が 把握しきれないので やる ことが 漏れが ち -
“ 良い 文章 ” よりも “ 良い
構造化 ” (全体のパフォーマンス向上) “ 良い 文章 ” に 時間を かけるより、 “ 良い 構造化 ” に 時間を かけた ほうが 使いまわせるので ランニングコストが 下がる \ (^o^) / ・セクション (#) を分ける ・実施フローを伝える ・ルール / 詳細説明などのファイルを明確に分ける ・変数を使う (AI はプレースホルダと解釈する) ・スクリプトを実行する ・テンプレートを用意する ・あえて使うツールやスキルを指定する ・実行単位を分ける 構造化には 様々な 手法が ある -
“ 構造化 ” の 例 (うん、 SpecKit
の ときの コピペ) -
“ 構造化 ” っていまどき そんなに 大事? 最近
AI の 性能が 上がってるのに なんで そんなに 頑張る 必要が あるの? ある 程度の 指示の 質で、 誰でも いい 感じに システム改修してくれるようになるから -
“ 構造化 ” っていうけど、 実際むずいんじゃね? " 忙しい
" 、 " 作り方が わからない " 、 " システムが 巨大化してて 不可能に 近い " うん。 AI に やらせようぜ\ (^O^) / -
「テック記事を 書く」と いう 行為を 精度を 上げる ために 適当に 小分けした プロンプト。
最後に 検証( レビュー) を 入れると 最終的な 成果物の 完成度が 上がる ため、 入れた ほうが よい。 各小分けプロンプト別に 守って ほしい ルールを 記載。 (検証していく 中で 「ないと ブレるな」と 思った ことを 追記していった) 参考に する URL から 全画像を ダウンロードする ための スクリプト (AI に 実行して もらう)。 画像は、 記事を 書く 上で 「その 画像が ないと 伝わらない」と 思った ときに AI に 見て もらう ために ダウンロードする 仕組みを 取り入れた。 各小分けプロンプトで Markdown ファイルを Output する ときに 使う テンプレートファイル( セクションのみ 定義してある)。 “ 構造化 ” の 例 (フォルダ構成例) -
実行フロー ロールや 発火制限に ついて 説明 (まず先に 読んで ほし いため)
プレースホルダー (変数) 定義。 プロンプト内で 使うことができる。 入力内容に 関する 説明 “ 構造化 ” の 例 ( Markdown 例) -
伝わる プロンプトの 実例 ( CodexCLI の
場合) この プロンプトは、 単体テストの パターンを 生成するための ものです。 $FILES は 設計書の パスを 表し、 $SHA1 は コミットの SHA-1( 変更履歴 ) を 表します。 これらの 情報に 基づき、 以下の 指示を 実行してください。 # あなたは 詳細な 試験観点を 出力する 優れた システム開発エンジニアです。 # 参照ルール (相対パスは この ファイル基準) - `templates/ 単体テストパターン作成 .md` を 読み、 出力フォーマットを 適用してください。 - `rules/ 単体テストパターン作成 .md` を 読み、 列ごとの 記載ルール・条件ルール・必須出力条件を 適用してください。 # フォールバック - 上記 2 ファイルが 見つからない 場合は、 その旨を 明記し、 代替と して 一般的な単体テスト観点 (正常 / 異常 / 境界 / 回帰)を 表形式で 提示してください。 / 単体テストパターン生成 $FILES= 手順書.md, 〇〇機能.md,×× 機能.md $SHA1=XXXXXXXXXXXXXXXX,XXXXXXXXXXXXXX AI には こう 伝える -
複雑な 依頼は フェーズ分割 1 回で いろいろ
盛り込まない。 分割で 精度を 上げて、 試行回数を 減らす。 1. 調査 依存関係の 調査 処理フローの 調査 修正箇所の 調査 2. 設計 構成案 採用 / 非採用理由 3. 実装 本文 / コード生成 4. レビュー 抜け漏れ 要件充足を検証 分割すると「どこで品質が落ちたか」を切り分けやすい。 精度が 低い、 コントロールが 難しいと 感じたら、 各フェーズを さらに 分ける ことも 検討する 慣れてきたり、 わかってきたら まとめるのも 手 -
GUI より CLI を選ぶべき理由 CLI は AI コーディングエージェント寄りに
動作する ため・・・ その 代わり、 操作完了まで 時間が かかりがち。 だから hooks を 使おう!! 生産性が 上がる!! ⚡ エディタ操作の 邪魔を しない 🙌 自分の作業の裏で動かせる(マルチタスク化) 💰 指示が テキストだけで 完結する 🎯 良い 成果を 出すことが 多い CLI = チャット専用画面 -
GUI より CLI を選ぶべき理由 ただ、 もっとも CLI を
使うべき 理由は・・・ イベント履歴が ローカルに 保持されるので、 イベント解析が できるからです!! -
GUI より CLI を選ぶべき理由 これに よって、 イベント
日時や セッションを 指定して 会話が できます。 " この 日時に 指示した やつです " みたいに 話せる これぞ地球が 何回まわった とき理論\ (^O^) / -
チームで効く共有資産設計 個人の成功パターンを、再利用可能な資産に変える。 運用資産 スクリプト (AI が 実行 ) カスタムエージェント
カスタムプロンプト スキル 自作 MCP 組織効果 品質の 底上げ オンボード短縮 ( 早期戦力化 ) 属人化の 解消 生産性の 向上 誰かが 作った 資産の 共有 働き方 改革に もつながる 入力 資産 依頼テンプレ ( 設計 / 製造用など ) コーディング規約 レビュー観点 システム構成図 AI 向けに カスタマイズした もの -
セキュリティ的に 許されるなら、 許される 範囲で AI の
無料枠を 使うのも 要検討。 free プランの 利用に ついて トークン制限、 リクエスト制限の 緩和に つながるのは たしか。 -
セキュリティ前提の運用ルール 必須ルール 個人情報・顧客情報・機密情報は入力しない 必要時はマスキングしてから投入する ログ保存範囲と公開範囲を事前確認する 社内ガイドラインに沿って手順を明文化する ルール化で よく
ある 詰まり ・ルールが多すぎて使われない ・更新されず古くなる ・担当者依存でブラックボックス化 free プランを 併用するなら・・・ 対策: AGEND.md 、 CLAUDE.md を グローバル参照フォルダに 配置する -
ありがちな お困り ごと ・フロントの コーディングで
デザイン調整が 難しい ・ AWS の 操作が 分からないけど うまく 画面が 説明できねえズ ・ AI との やりとりを 見返したいけど探すの しんど ( #-`д-) ビキビキ ・プロジェクトごと、 タスクごとに 設定変えたいけど めんどい ・マルチタスクっていうけどさ。 同時に CLI 動かすの しんどい -
ありがちな お困り ごと AI との やりとりを
見返したいけど探すの しんど ( #-`д-) ビキビキ GitHub Copilot Session Viewer Codex Session Viewer Claude Session Viewer え? PC 内の チャット履歴を 検索する ツール作ったよ? あなた 作らないの? ( ˙σ-˙ ) ホジホジ -
ありがちな お困り ごと フロントの コーディングで
デザイン調整が 難しい AWS の 操作が 分からないけど うまく 画面が 説明できねえズ ほ~ん、 画面を AI に 見せる ための MCP 作ったけど 何か? あ、 1 時間くらい かかっちゃったかも ( * ノノ) Capture Screen MCP -
プロジェクトごと、 タスクごとに 設定変えたいけど めんどい Bandle Manager
VS Code 拡張機能 なんか ごめんね・・・ 別の ことやりながら 1 時間で 作ったけど・・・ ワークスペース設定/ ファイル/ フォルダの マージ、 ワークスペースへの フォルダ追加が できるよ\(^O^) / ありがちな お困り ごと -
マルチタスクっていうけどさ。 同時に CLI 動かすの しんどい Bandle
Manager VS Code 拡張機能 ふーん、 プロセス管理するy・・ (略 ありがちな お困り ごと -
結論 AI に お願い すれば VS Code
拡張機能も Chrome 拡張機能も MCP サーバーも 様々な ツールは ある 程度の ものは 簡単に 作れる 時代なので、 AI に 頑張って もら おう \ (^O^) / 遊びながら 仕事できる 時代が きたって ことですね ありがちな お困り ごと -
・コスパを 意識した AI 活用方 法 ・
使用制限を 回避するには 再試行を 減らすには (壁打ちを 減らそう) まとめ -
色々 言ったけれども、 結局 こういう ことだと
思う 1. AI が 理解しやすいように ドキュメント整備せい ディレクトリ構成、 クラス図、 シーケンス図。 いままで めんどく さくて 作らなかった 設計図を 作れい 2. 構造化を 作るのが 難しいなら AI に やらせい どうせ人が やった ところで 完璧には できない。 やりながら 直せばいい。 3. 説明力は うまい やつが スキル化せい 必ずしも 説明力を 磨く 必要は ない。 チームなんだから 説明 うまい 人が スキル化すれば いい 4. AI 活用する ための ツールを AI 自身に 作らせまくれい そも そも これくらいの ことは やった ほうが いい スクリプトが 必要な パターンは その中で 見えてくる -
色々 言ったけれども、 結局 こういう ことだと
思う 5. トークンが よく わからないなら GitHub Copilot に せい そも そも ここまでで トークンが わからないなら コスト管理難しいから トークンモデル 使わない ほうが いい 6. うまく いった 指示は スキル化せい セッション A は うまく いって セッション B は 失敗する ことがある。 なら A で スキルを 作れ 7. AI で 逆に 大変に なった? なら ツール作れい ツールを AI で 作りまくって、 AI で 職場環境悪化したなら AI で 職場環境を 改善した ほうが いい 8. 生産性 上がらない? なら 自動化するか プロダクトみな おせい GitHubCopilot の プレミアムリクエストは 1 リクエスト =0.04 ドル (6 円ちょい ) 。 GitHubCopilot Coding Agent を 使えば、 出社時、 ランチ前、 退社時に 動かして 放置できる \ (^O^) / スクリプトが 必要な パターンは その中で 見えてくる トークン型の AI 合わないんじゃない? こぱろうぜ