Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
AIのバカさ加減に怒る前にやっておくこと
Search
k2moons
October 29, 2025
Programming
0
110
AIのバカさ加減に怒る前にやっておくこと
存在しないAPIを捏造したり、実装を忘れたりする生成AIにモヤモヤする日々、指示を明確に出し、読むべき文書を体系化し、履歴を記録・共有することで、生成AIとの改善を目指す
k2moons
October 29, 2025
Tweet
Share
Other Decks in Programming
See All in Programming
When Dependencies Fail: Building Antifragile Applications in a Fragile World
selcukusta
0
110
Server Side Kotlin Meetup vol.16: 内部動作を理解して ハイパフォーマンスなサーバサイド Kotlin アプリケーションを書こう
ternbusty
3
260
CSC305 Lecture 11
javiergs
PRO
0
310
バッチ処理を「状態の記録」から「事実の記録」へ
panda728
PRO
0
190
「ちょっと古いから」って避けてた技術書、今だからこそ読もう
mottyzzz
12
7.2k
フロントエンド開発のためのブラウザ組み込みAI入門
masashi
7
3.6k
社会人になっても趣味開発を続けたい! / traPavilion
mazrean
1
110
CSC305 Lecture 09
javiergs
PRO
0
320
Devoxx BE - Local Development in the AI Era
kdubois
0
150
品質ワークショップをやってみた
nealle
0
650
O Que É e Como Funciona o PHP-FPM?
marcelgsantos
0
210
Vueのバリデーション、結局どれを選べばいい? ― 自作バリデーションの限界と、脱却までの道のり ― / Which Vue Validation Library Should We Really Use? The Limits of Self-Made Validation and How I Finally Moved On
neginasu
2
1.7k
Featured
See All Featured
Unsuck your backbone
ammeep
671
58k
The Illustrated Children's Guide to Kubernetes
chrisshort
49
51k
4 Signs Your Business is Dying
shpigford
186
22k
Mobile First: as difficult as doing things right
swwweet
225
10k
I Don’t Have Time: Getting Over the Fear to Launch Your Podcast
jcasabona
34
2.5k
KATA
mclloyd
PRO
32
15k
Art, The Web, and Tiny UX
lynnandtonic
303
21k
"I'm Feeling Lucky" - Building Great Search Experiences for Today's Users (#IAC19)
danielanewman
230
22k
Imperfection Machines: The Place of Print at Facebook
scottboms
269
13k
How STYLIGHT went responsive
nonsquared
100
5.9k
How To Stay Up To Date on Web Technology
chriscoyier
791
250k
Reflections from 52 weeks, 52 projects
jeffersonlam
355
21k
Transcript
AI のバカさ加減に怒る前に、 やっておくこと とらさん(k2moons ) AI を“ 相棒” にするための勉強会 2025/10/29
自己紹介 名前:とらさん(k2moons ) 所属: 株式会社ゆめみ 仕事:iOS エンジニア X : k2_moons
Github : BlueEventHorizon 好きな生成AI : Claude Code
バカさ加減に怒った事例
存在しないAPI を捏造して認めない Gemini 「XXXX(...) というメソッドがあります」と回答 公式ドキュメントに存在しない 「 無いからちゃんと読め 」 →「
公式ドキュメントにあります 」 → 「 無いからちゃんと読め 」の 無限ループ に陥る
やったこと Ctl+C
呼び出す関数を、推測で決め打ちして実装 Claude Code 「fetchAllResults(sortedBy: .date) 」という架空の便利関数を呼び 出す 実際は getAll() と
sort() を組み合わせる必要があった
やったこと ビルドエラーを指摘して、 「ちゃんとコードを読んだのか」と説教 「コードを読んでいませんでした」と謝罪したのでモヤモヤしなが ら許す
やったことを忘れる問題 実装済みのクラスや関数を忘れて、もう一回同じやつを実装 設計書に書いてあるルールを守らない 余計な機能や実装を入れてくる
やったこと レビューで指示を出しまくる 疲れる
Gemini は論外 今は進化してちゃんとしてます!(たぶん) なるべく楽したいと思っている 言われないと文書を読まない もの忘れが激しい
どうする?
毎回やるべきことを提示し直す? 文書をきっちり指定する? やったことを記録する?
毎回やるべきことを提示し直す? 文書をきっちり指定する? まず文書体系を考える やったことを記録する?
> Project ├─ docs/ … プロジェクト横断の開発基盤 │ ├─ rules/ …
開発ルール │ │ ├─ project_rule.md … AIの役割 │ │ ├─ common/ … アーキテクチャ │ │ ├─ layers/ … レイヤー毎の実装ルールなど │ ├─ workflow/ … 作業手順 │ │ ├─ plan/ … 要件抽出→設計→計画作成 │ │ ├─ dev/ … タスク制御とAgent実装手順 │ │ └─ refactoring/ … リファクタリング │ └─ format/ … 要件/設計/計画/ヘッダーのテンプレート │ └─ project_docs/ … プロジェクト固有の知識・計画 ├─ spec/ … 要件定義カタログ │ ├─ architecture/ … アーキテクチャ │ ├─ business_logic/ … ビジネスロジック仕様 │ ├─ functions/ … 機能横断要件 │ ├─ screens/ … 画面仕様 │ ├─ ui_components/ … 再利用UI要件 │ └─ non_functional/ … 非機能要件 ├─ design/ … 設計書 ├─ plan/ │ └─ main_plan.md … 計画書 └─ history/ … 会話記録
None
特徴 iOS 開発汎用の文書と、アプリ固有の文書に分かれている ルールとワークフロー 要件定義、設計書、計画書をリンク 課題 非常に数が多い
毎回やるべきことを提示し直す? 指示を出す 文書をきっちり指定する? やったことを記録する?
Claud Code の場合 Sub Agents を使うと便利です。
便利だけど大変です。 親の Claude Code から Context を渡せるので 親の Calude Code
向けのワークフローを用意する 受け取った Sub Agent のワークフローを用意する Sub Agent 毎に必読文書リストを定義
書き方 絶対に読んでもらわないといけない文書は、 [CRITICAL] 下記の文書を全て読み込み、深く理解すること - `docs/workflow/dev/task_execution_workflow.md`
課題 文書が増えてくるとメンテナンスできない
毎回やるべきことを提示し直す? 文書をきっちり指定する? やったことを記録する? 記録する
検討してきた内容、対話した内容を記録する # 検討してきた内容、対話した内容を簡潔に履歴にまとめる ## CONVERSATION_HISTORY 今まで検討してきた内容、対話した内容を簡潔に履歴にまとめてください。 ファイルは、`project/history/CONVERSATION_HISTORY.md` です。 存在する場合は、追記して下さい。 存在しない場合は作成して記入
してください。 ## LATEST_CONVERSATION_HISTORY `project/history/CONVERSATION_HISTORY.md` の中から、新しい生成AIに必ず知って貰いたい開発の経緯を、 `project/history/LATEST_CONVERSATION_HISTORY.md` として 2000文字以内でピックアップして記録してください。 存在する場合は、削除して構いません。編集してもOKです。
今まで検討してきた内容、対話した重要内容を読み込 む # 今まで検討してきた内容、対話した重要内容を読み込む `project/history/LATEST_CONVERSATION_HISTORY.md` を読んで、深く理解してください。 不明点は、`project/history/CONVERSATION_HISTORY.md` を読むと分かるかもしれません。
文書をきっちり指定する? PageIndex https://github.com/VectifyAI/PageIndex に触発される
RAG (Retrieval-Augmented Generation ) は、文書検索で「意味的 な類似性」に依存。しかし、類似性は必ずしも関連性を意味しない。 専門的で長文の文書を扱う場合、単なる類似検索では、重要な情報を 取り出すことが難しい。 推論型RAG システムを提案。PageIndex
は、人間の専門家が長文ドキ ュメントを読む際の「探索と推論」の過程を模倣し、ツリー探索を通 じて最も関連性の高い部分を特定する。 1. ドキュメント全体から「目次(Table of Contents ) 」に相当するツ リー構造のインデックスを生成する。 2. そのツリー構造上で 推論に基づく探索(ツリーサーチ)を行い 、 最も関連性の高い箇所を取得する。
# 開発文書検索インデックス --- name: 開発文書検索インデックス description: AI活用iOS開発における、要件定義から実装までの全工程で参照すべき ルール・ワークフロー・フォーマット文書を体系的に整理した検索インデックス。 Clean Architecture、Actor並行性、Protocol-based
DIに基づく開発指針を提供。 --- ## このTOCの使い方 1. **Quick Reference**: 最重要文書を特定(常に参照すべき文書、実装時に参照する文書) 2. **カテゴリ別概要**: 開発工程ごとの文書分類(rules/workflow/format) 3. **キーワードインデックス**: 具体的な実装内容を検索(Service実装、Entity定義、データフロー等) 4. **ディレクトリ別詳細目次**: 全文書の要約と主要トピック 5. **文書間の関係性マップ**: 要件定義→設計→計画→実装の流れ 6. **タグ別インデックス**: 実装層別検索(#Domain, #UI, #Infrastructure, #Architecture等)
Claud Code の場合 Skills を使うと便利です。
コードは、どう読ませる?問題
Serene https://github.com/oraios/serena
Swift-Selena 自作しました https://github.com/BlueEventHorizon/Swift-Selena
まとめ 何を読ませる どう読ませる まだまだ試行錯誤してます