僕の考えたAI構成（備忘録）
ただの備忘録です。拙いです
概要
AIを使いたいといっても
いきなり、工程を変え、AIはこうだ！みたいなことをみんな言ってる。
やり方を調べたところでいきなり僕みたいな仕事してる人間が適用できるわけはない・・・
ので、よくある工程で使うためにはどうしたらいいんだろうと思って、考えてみた。
- 契約が工程で切ってある（要件定義までいくら、設計でいくら）
- 設計書が納品物。レビューと承認の記録も要る
- 複数社で分担しているので、自分たちだけ工程を変えられない
- 検収・監査で「どの要件がどこに落ちたか」を説明する必要がある
つまり
要件定義 → 基本設計 → 詳細設計 → 実装 → 単体テスト → 結合テスト は動かせない。
ウォーターフォール大好き！な人は多いし、わかりやすい。
その形は、なかなか動かせないし、動かさない方が、みんなが納得しやすい。でも、AI を使いたい。じゃあどうする？って思いました。
変えればいいじゃん？いやいや、まず今の状態で、AI使いたいって話から徐々にやっていかないと組織によってはとても難しい
要点だけ知りたい人向け
- よくあるウォーターフォールの各フェーズごとにスキルを作ってみた
- 今後もこれベースでいろいろ考えられたらよさそう
- 実際の評価はあんまりしてない。考え方の整理、備忘録
実際に使ったスキル、使ってないスキルで、バラバラあるので、正式な評価はしてないです（ただの備忘録なので許して）。 - スキル公開してない
※基本設計や詳細設計は使ってみてある程度いい感じだった
初心者の勉強用です。
AI使うときの問題点
一度案件でAIを使っていろいろためしてやった
ただ
-
プロンプトがちがう — 人によっても日によっても違うので、成果物の粒度が揃わない
（ルールづけしたり、CLAUDE.md揃えても微調整は各自だったり・・・） - レビューを忘れる（というか難しい） — AIの、特に文章は全部それっぽいので、間違っていても気づきにくい
- コンテキストが汚れる — 1つのセッションで全工程をやると、前半の話が後半に効かなくなる
よくネットで見かける問題点を肌で感じました。
何を作ろうと思ったか
コンテキストだの、プロンプトだのいろいろお話を聞きながら、うまくやるためには・・・とちょっと勉強してみた
どうやら、スキルだのコマンドだのを作るべきという話や、コンテキストをまっさらな状態でレビュー回すべきとか聞いた。
多少やってたけど難しいなと思いつつ
なので要件定義 → 基本設計 → 詳細設計 → 実装 → 単体テスト → 結合テスト を、
工程ごとのスキルで回すテンプレートを作ってみようと思って作ってみた。
例えば、「要件定義スキル」を起動すると、AI が
- 「対象はインフラ？アプリ？両方？」
- 「入力資料はこのファイル群でいい？」
- 「要件定義書の目次案、これでいい？」
と順に聞いてくる。OK を出した範囲だけ書いてもらう。
書き終わるとレビュー役の AI が別で走って指摘を返し、人が承認したら次の工程へ進む。
考えた成果物生成のシーケンス例
基本設計を例に「作成 → レビュー → 是正」の一周をシーケンスで示す。
人が直接、生成AIで触ると品質がぶれて面倒なので極力、スキル発で編集させたい（願望）で考えてみた。
全体設計、全体反映が基本になると、個人で開発するみたいになってしまうので、一旦ドラフト版作成や
全体設計変更時のスキルの側面が大きい。
もちろんこれで、片が付くのであれば、このスキルだけでいろいろとやれればいいのに・・・
もし、チームでそれぞれの章ごとに編集をやるなら、個別の章ごとに、生成するとか必要か？と思ったりする
スキル再実行
スキル自体は、何度でも回せるように、また調整事項が必要なものは別途ファイルにまとめた。
基本はAWSのベストプラクティスベース。
AIとして少しでも判断や実現可能性に悩む部分があれば、調整事項として、外部にファイル出力させている。
また、その調整事項には個別の追加要件をしっかり記載できるようにした。
（前フェーズから読み取れない設計方針、実装方針などなど）
追加要件を定義しつつ、一般的なベストプラクティスを守る条件ようにしている。
全体構成
上記の基本設計をほかにも当てはめてそれぞれスキルとエージェントの構成を作って考えてみた。
他にも移行だったりを考える必要はあると思いつつも、基本構成だけ考えて作ってみた
個別で直すとき
毎回いろんなインプットがあると雑多なので、個別に修正する。
ただ修正ルールはスキルに記載したいので、別途スキルを作って個別対応する。
ここからきっと、MCPとかいろんなのがはまってきて、
みんなでレビューしまくるようになると思う・・・。
多分ね
面倒なところ
確認が多い
ゲートを通すたびに人が承認する。慣れるまでは「AI君さぁ頑張ってよォ」とかなる。
文書量が重い
受託で設計書を納品する前提の構成なので、個人開発や PoC には要らないだろうし。
「とりあえず動くもの」が欲しいときにこれを使うと、トークンましましになる。
AI レビューは万能じゃない
レビュー役も普通に見落とす。「AI レビューを通ったから大丈夫」は成立しない。
面倒だけどしょうがない。
小回りが効かない
実装しながら設計を直す、みたいな動き方とは相性が悪い。
手戻りは「上流を直してから下流をやり直す」が原則なので、正しいけど遅い。
工程を変えられる現場なら、たぶん要らない
そもそもの出発点が「工程を動かせない」だったので、動かせるならもっといいやり方があると思う。
まだ改善したいこと
スキルのエージェントをもう少し細分化すると
モデルをより細分化してトークンの消費を減らせるのかと思った。
- 計画用生成エージェント
- 実装、追記用エージェント
- レビュー（誤字脱字）
- レビュー（実現可能性）
- レビュー（整合性）
とか？
まとめ
とりあえず生成AI活用って大変なんだなと思った
でも明らかに自分のやりたいことをやりやすい環境になりつつあると思うので、考えていきたいなと思った
Claude、Kiro、Codexが手元にあるんだけど、コレを共通化出来たらいいのに・・・
今は一つのモデルでメインスキルを作って、他からラッパー形式で読んでるけど
トークン消費持ってかれてるんだろうな
細かい部分はまだまだ足りないと思っている
あと、一度作ってしまうと、これ以外のいろんな正しい形があっても、1から作り直すということをしないと
全く別の形にもっていくのはAI君が嫌うんだなって思いました