okm-ssy

弊社史上初の競プロer

[okm-ssy @okm_dev_000]

きた
#gdgtokyo #DevFest

[okm-ssy @okm_dev_000]

CloudSign powered by 弁護士ドットコムのブースに行きました。結果はパーフェクト！
#vuefes_bengo4 #vuefes
https://t.co/TvnVqanX2E

[okm-ssy @okm_dev_000]

#vuefes_uv

[okm-ssy @okm_dev_000]

座談会
#LINEDC

[okm-ssy @okm_dev_000]

使い方
1. まず、とりあえず取り入れてみる
2. 明示的にエージェントを呼び出してみる
3. 特に有効な手法を取り入れる
- レビューエージェント
- 調査タスクエージェント
- エージェント召喚スラッシュコマンド

#LINEDC

[okm-ssy @okm_dev_000]

カスタムサブエージェント
CC は大きな作業は苦手なので、うまくタスクを分割するために使う
auto-compact を避けたり
#LINEDC

[okm-ssy @okm_dev_000]

「カスタム」サブエージェント
サブエージェント自体は前からあったみたい

カスタムサブエージェントの利点は、 Markdown で定義できることにある
#LINEDC

[okm-ssy @okm_dev_000]

サブエージェント！
特定のタスクに特化したサブエージェント

主流の CC とコンテキストウインドウが独立
並列実行できる
自動で呼び出される
md 管理による再利用性 (repo へのコミットなどできる)
#LINEDC

[okm-ssy @okm_dev_000]

Claude Code カスタムサブエージェント活用術
#LINEDC

[okm-ssy @okm_dev_000]

自動テストのループ
品質を担保するガード
があれば、アプリが作れる

逆説的に
静的解析で品質を担保しやすい設計にする
#LINEDC

[okm-ssy @okm_dev_000]

課題：
コード生成と修正の効率が悪い

解決：
hooks で formatter と lint をする
ついでに rm -rf ~/ が含まれないかも hooks で確認させる
#LINEDC

[okm-ssy @okm_dev_000]

課題：
余計な実装が無限増殖する

解決：
linter ルールでやりがちな実装を禁止する
修正方法を明記する

Factory をつくって、テストデータの作成は Factory で作るような lint エラーを出させる
#LINEDC

[okm-ssy @okm_dev_000]

テストがないバックエンドのコードが、
全自動でテストが書けるようになった
#LINEDC

[okm-ssy @okm_dev_000]

Claude Code で 600 テストケースを書いて得た知見
#LINEDC

[okm-ssy @okm_dev_000]

開発で作ったドキュメントはすぐ消す。
ドキュメント作成の価値が変わってきており、いまや短期施策になっている。

メッセージ：
ドキュメントは投資じゃない、飲んだらすぐ聞くエナドリだ！
#LINEDC

[okm-ssy @okm_dev_000]

知識のないコードベースで CC をうまく使えないのは、1ターンで勝とうとするから難しくなっている

1. 挙動確認
2. 挙動のドキュメントを作ってもらう
これを繰り返す
3. 人間が開発できそうになったら、チケットの情報を入力して作業してもらう

#LINEDC

[okm-ssy @okm_dev_000]

状態価値関数 = 人間 が改善しないと、強化学習である CC も改善されていかない。本当？
ここまでが前段
#LINEDC

[okm-ssy @okm_dev_000]

Vibe Conding は Actor-Critic 法 (強化学習のアルゴリズム (?) )
つまり、人間もエージェントの一部
#LINEDC

[okm-ssy @okm_dev_000]

「エージェント」といえば、強化学習

AI の基本は強化学習にあたる問題設定
環境・行動・報酬
#LINEDC

[okm-ssy @okm_dev_000]

#LINEDC

[okm-ssy @okm_dev_000]

無知な状態で無策で CC に任せて発生したこと
1. AI に与えるコンテキストの質が低い
2. 指示が足りず、暴走する
3. 修正の方針が正しいのか理解できない
→ CC の活用にも戦略が必要！！！