(12月17日にソウルの Claude Code Meetup で発表した資料です。発表資料全体はこのリンクを参照してください。)
コルカ AX チームの「社内コンサルティング」の目標
- コルカに良いエージェンティック・エンジニアリングの実践法を根付かせ、ともに継続的に発展できる土壌を作る。
- コルカでは「エージェンティック・エンジニアリングの実践法」を「ソフトウェアの品質と生産性をともに高める方向で AI エージェントを活用するための実践方法」と定義
- エンジニアリング能力がコルカのもう一つの中核競争力になるようにする。
- そのために Moonlight チームを支援する取り組みを始めた
Moonlightの状況
- コルカの代表製品である Moonlight は、「一緒に論文を読む AI 同僚」を掲げている
- 「PDF と対話する」は ChatGPT のごく初期から存在したアイテム。そのような数多くの競合製品の中で生き残り、最近は J カーブの初期段階にある（最近は中国での登録者が急増）
- ここに至るまで数多くの試行錯誤があったが、中核競争力は機能開発のスピードとリズムを「なんとかして」維持すること
- スピードのためのいくつかの初期意思決定
- typescript strict: false
- 自動テストは最小限
- 重複とハードコーディングを許容
- 職種の区分なし。チームメンバーのほとんど全員（7人中6人）がコーディングエージェントで実装し、PR を上げる
- 軌道に乗ると、負債のために少しずつ苦しくなってきた
- 製品が複雑化し、チームの新メンバーが増え、同時に走る実験も多くなった
- 製品改善のスピードは少しずつ遅くなり、不安は少しずつ大きくなった
- 数人にコードレビュー負荷が集中し、大小さまざまなミスが生じた
AX チームにとって差し迫った課題
- [製品] Moonlight の製品品質を向上させながら、機能追加と改善のスピードも上げよう！
- [チーム] 誰もが Moonlight のコードをより修正しやすくなり、デプロイ後のストレスをより減らそう！
- [文化] 1 と 2 のために、Moonlight チームと AX チームが協業して、良いエージェンティック・エンジニアリングの実践法を発見し、適用し、高度化し、段階的に社内へ広めよう！
→ コーディングエージェントがより良い応答を返せるようになれば、大半は解決できると見ていた
エージェントがより良い応答を返すには？
[1] 最初から良い経路に進ませる
- コードベースの品質が高ければ、3つの側面で有利になる
- 不要なコンテキストを減らせる（Less is More）
- エージェントが既存の良いパターンを真似るようになる
- 事前学習済みコードの中でも、高品質なコードが集まる領域からサンプリングされた応答が出やすくなるようにバイアスをかけられる
- 高品質なコンテキストを与えると良い応答が出るという研究は多い。
- （個人的推測）import 順が整えられたコードベースでエージェントに依頼したら？ 事前学習済みコードの中でも import 順を整えているコードは全体として高品質である可能性が高いのではないか？
- Anthropic ブログより: "興味深いフォントを使わせるだけでも、他のデザイン要素まで改善される"
[2] 間違った経路に進めないようにする
- 型エラー確認、リンターエラー確認、自動テスト、デッドコード検査、ファイル長検査、複雑度検査、依存関係の強制、テストコードと本番コードの比率の強制など、さまざまな静的解析ツールで誤った経路を遮断できる（基準を通過するまで再度作業させる）
[3] 得意な仕事を中心に依頼する
- 人が得意なこと、LLM が得意なこと、アルゴリズムが得意なことは異なる。いつ何を使うか賢く選べば、時間とコストを節約できる
- 例: i18n key を漏らさないようにと言う vs 漏れた i18n key を探すスクリプトを回してみるように言う
- 誰がいつ何を得意とするかは、時間の経過や問題領域によって変わる。自分の領域でこの「勘」を更新し続ける習慣を持てば有利
- 例: 新しいモデルが出たら自分なりのベンチマークで試してみる、有名なソーシャルメディアの例をなぞってみる
[4] できないことは支援する
- ただし、本当にできないのかは常に確認が必要。委任するには危険、あるいは極端に非効率といった理由でなければ、人よりも AI / アルゴリズムに多く任せた方がよい。（トークンコストはいずれ電気代レベルまで安くなるため）
- 本当にできないなら？ 別の LLM にレビューさせる
- 例: 一番簡単なのは、「これは初心者開発者が書いたのですが…」
- AI により良く働いてもらうには、AI がより良く働ける環境を提供する必要がある。言い換えれば、（現在の）エージェントが（ここでは）苦手そうなことを、人とアルゴリズムと別のエージェントが補強してあげる必要がある
注意していたこと
- Moonlight は今まさに飛び始めたロケットであり、AX チームは外から来たゲスト
- 外部の人が来て何かを「やってあげて」帰る構図は絶対に避ける
- 品質向上の取り組みが機能開発の足を（できるだけ）引っ張らないようにする
- 普段の働き方を大きく変えない種類の仕事と、挑戦的だが効果的な種類の仕事を適切な比率で混ぜることにした
→ AX チームと Moonlight チームが「一緒に」チームと製品に合った実践法を見つけて適用し、その過程でコードと製品の品質、そしてチームの能力向上が同時に起こる姿を思い描いた
この4週間で得られた代表的な成果
[1] 良い習慣が定着し、良いパターンが見つかりつつある
- 毎日、PR レビューなしでごく小さなリファクタリング（tidying）コミットを上げる
- 過去の模範的なコミットを（新規モデル対応などで）踏襲するプロンプト、そうしたパターンを発見して集めるプロンプト
- シニアになりきったコードレビュー SKILL
[2] コード品質指標の測定と可視化を開始。コード行数に対するエラー/警告数が
急速に減っている
- コード品質指標は、ときには漸進的に、ときには劇的に減少している
- tidying が毎日のようにコードベースを少しずつ改善することで、ある時点で大きなリファクタリングや大きな作業にも踏み出せるという見通しが持てたことが大きい
- knipをパッケージごとに適用し、古くて使われていないコードも削除
- 指標は常に相補的であるべき。1000行のコードでエラーが1000個出るより、10万行のコードで5000個出る方がはるかに良い。だから単純な個数だけでなく、行数に対するエラー率を見ることで、より健全な管理指標を設定
- コメントと空行を除いた意味のある行数は tokei で測定
[3] 1年以上続いていたメモリリーク問題を修正
- repomixをはじめとする複数のツールとプロンプティングを総動員し、何度かの試行の末に1年以上続いていたメモリリーク問題を解消
- サーバーインスタンスのティアを下げられそうで喜んでいる
[4] 毎週いくつも並行して回る実験を、より簡単かつ安全に追加・削除できる抽象化構造、プロンプト、スクリプトができた
結果として、コード品質は着実に高まり、機能開発はより安全でありながら速くなり、チームの（エージェンティックな）エンジニアリング能力も継続的に高まるという三拍子がうまくかみ合っている
試行錯誤
- 当然ながら最初からうまくいったわけではない。もともとは2つを同時にやりたかった
- 不安はあっても価値の大きい変化を一度に導入する: strict オプションを有効化、厳しい eslint ルールを導入、デッドコードを一気に削除 など
- 価値は小さくても安全に一歩ずつ進む: 毎日 tidying コミットを残す など
- しかし前者は不安で「できず」、後者は面白くなくて「やらなく」なった
- 代わりにこう変えた
- 挑戦的なことをより安全に（1ファイルずつ tsc strict を有効化して修正後に戻す、最小限のルールで eslint を適用、1パッケージに1つずつ knip を適用 など）
- 安全なことをより価値あるものに（最近の変更について tidying の提案を受けるプロンプトを作る など）
- まだ多くの課題が残っているが
- typescript: strict を有効化
- zod を導入してサーバー-クライアント間の契約を合わせる
- より厳しい eslint rule の導入
- より高い自動テストカバレッジ
- より多様な静的検査ツールで誤った経路を塞ぐ
- 一緒に、継続して、決して遅くなく前進している
One More Thing: 私の学習 + デバッグ習慣
こうした状況で AI に質問し、上級者にも尋ねてクロスチェックすると学ぶことが多い。この過程も GitHub PR や Issue、Slack に残して組織に共有している
- 私の知らないことを他の人が知っている
- この知識/経験をその人はどうやって得たのだろうか？ どんなシグナルでこの問題を把握したのだろうか？
- 自分のミスやバグ、コードベースのアンチパターンなどを発見する
- この問題が起こらざるを得なかった原因は何だったのか？ 次にミスを減らし、より早くミスを発見するには、どのように構造を改善すればよいのか？
まとめ
- AI がより良い応答を返せるようにすると、プロダクトチームの問題のかなりの部分は解ける
- コードベースの品質を高め（最初から良い経路へ）、さまざまなツールを導入し（誤った経路を遮断）
- メンバーのエージェンティック・エンジニアリング能力が高まるよう支援しよう（得意なことは依頼し、苦手なことは支援する）
- AI と賢く協力することでチームの能力が高まり、良い環境が整えば、「品質向上」と「機能追加/改善スピード向上」は同時に十分実現できる
- 「外から」良いものを持ち込んで助けるのではなく、「内側で」一緒に発見し、試していこう。測定し、可視化し、祝福し、互いに学ぼう
3件のコメント
ミートアップ記事も出ましたね。
[ルポ] 「韓国でClaude 1位ユーザー誕生」…Anthropicミートアップイベントに行ってみた
https://n.news.naver.com/mnews/article/092/0002402940
> この日、世界でClaude Codeを最も多く活用したPsyonicAIのパク・ジニョンエンジニアも参加し、エージェント活用のノウハウを共有した。
> これに先立ちAnthropicは、パクエンジニアがグローバルヘビーユーザー1位だと明らかにしていた。彼は現在、Claude Codeを含む複数のAIツールを業務に活用している。毎月のAIサブスクリプション料金として約180万円を支出している。
1か月に約180万円、すごすぎる
ジュニア開発者の積極的な参加と成長を後押しできる方法としても意味がありそうですね
あ、そうです（笑） そちらの方向でも一生懸命やっています