イベント参加: AI Coding Meetup #1 - チーム開発 ✕ AI、みんなの実践知 #aicoding
2025年4月8日開催された、「AI Coding Meetup #1 - チーム開発 ✕ AI、みんなの実践知」というイベントにオンライン参加してきました。
以下、各セッションの学びや気づきのメモ。
Devin時代の開発組織
株式会社Helpfeel プロダクトエンジニア - Teramoto Daikiさん @teramotodaiki
以下のメッセージが印象に残った。
- 今後、エンジニアリングの焦点が「アウトプット」から「アウトカム」に移っていく
- 判断や意思決定能力に優れた人がよりうまくAIを使いこなせるので、そういう人をどうやって増やしていくかが重要になっていく
個人的には、一人ひとりの創造性が最大限発揮されることに焦点を当てた組織設計が、今後ますます重要になってくるんじゃないかと考えていて、お話の内容とその考えを勝手に結びつけながら聞いていた。
大きな裁量が与えられた環境の中で、一人ひとりがアウトカムを追求するために、自由な発想とAIツールを駆使しながら、学習ループを回し、判断力や意思決定力を磨き上げていく。
個人の働き方も変える必要があるけど、組織のあり方も変わるべきだと改めて思った。
AI Coding Agent Enablment エージェントを自走させよう
Ubie株式会社 VP of Technology - Yuku Kotaniさん @yukukotani
AI Coding Agentを自走（＝Human-in-the-loop をなるべくやらない）させるためにできること。基本的には「エージェントにとって広すぎる「解空間」をどのようにして絞るか」という問いに対して工夫をすることになるが、その中で
- LLM のアウトプットをLinterや自動テストで機械的に検査してフィードバックする
- MCP や Rules等で解空間の定義を与える
の２つのアプローチを紹介されていた。
印象に残ったのは、解空間の定義を与えるためにRulesではなくMCPを使っている理由として、「現行のモデルやエージェントの特性として、実際に試したらMCPの方が精度が良かったから」とおっしゃっていたこと。あーだこーだと机上で比較・検討する前に、とにかく自分で実際に試してみないとわからないことがある。これは自分が取り組む時もすごく大事にしたいと思った。
また、MCP や Rules といった LLM への知識の入力方法はどんどん進化・変化するから、それよりも入力に値するドキュメントや情報を整備することが重要という話もされていた。MCP がものすごくバズっている直近だからこそ、自分も本質を見失わないようにしたい。
ためす、つくる、Model Context Protocol
株式会社LayerX バクラク事業部 CTO - Yoshiki Nakagawaさん @yyoshiki41
Design Docなどの開発ドキュメントをコードベースと同じ場所（つまりリポジトリ）で管理しつつ、LLMがドキュメントを直接参照するのではなくて、MCP Documentation Server 経由で検索させる取り組みについて紹介されていた。
Layer Xさんは、アーキテクチャやインタフェースなどが記載されたDesign Docが、もう300ファイル以上もあるらしい。Notion のドキュメントをMarkdownに変換するスクリプトを自作したとのことだけど、それよりも設計上の意思決定やスナップショット情報を、Design Docの形で資産としてこれまで積み重ねられてきていることが素晴らしい。
また、MCP Documentation Server は mastra のリポジトリに登録されたMCPサーバ を参考に開発されたとのこと。自リポジトリのドキュメント検索用に、リポジトリにMCPサーバの実装を組み込む方法はいいなと思った。
LLMに直接ドキュメントを参照させるのではなく、MCPサーバを介させることで、検索ロジックをカスタマイズしたり精度を改善したりがやりやすくなる。また、異なるIDEでも同じ仕組みでLLMに知識をインプットする変換サーバとして機能できるかもしれないなと、色々アイデアが浮かんできてきてすぐに試してみたくなった。自分のプロジェクトでも大いに参考にしたい。
AIコーディングワークフローへの挑戦
株式会社ログラス ソフトウェアエンジニア - kagayaさん @ry0_kaga
- 変更希望内容をSlackで書いてスタンプ押したらPull Requestが作られる
- mainブランチにマージされたら、自動でドキュメントやFAQ更新される
のようなワークフローを、Slack や Zapier、GitHub Actions、Devin を駆使して構築されている事例の紹介。
Devin APIを使うと、GitHub Actionsからいろんな作業をDevinに依頼できるのはとても便利そう。リポジトリで管理するようにした Design Doc を最新の状態に更新したり、リリースノートを作ってもらったりと、反復作業で作業量もそこそこ多いタスクに対して活用できるイメージがとてもわく。
なかなか、AIコーディングツールの利用が進まなかったり、ついつい自分の手で開発しようとしちゃったりってよくある話だけど、こうやってワークフローの一部に組み込んでしまうことで、人間の意思関係なく、AIの活用と学習の蓄積がぐんぐん進むのが非常にいいなと思った。
"知のインストール"戦略：テキスト資産をAIの文脈理解に活かす
株式会社ナレッジワーク AIエンジニア - zawakinさん @zawawahoge
LLMのコンテキストサイズが大きくなってもなかなか解決が難しい、文化や歴史的経緯、暗黙のルール、思想のニュアンスといった「暗黙知」をどのようにLLMに伝えるか、という課題に対する工夫の紹介。
ひとつの例として、GitHub の Pull Requestのコメントを元データとして、そこからルールを収集し、ルールから原則を抽出し、最後にAI Codingツールに活かす事例について紹介されていた。
いくらLLMが非構造化データに強いといっても、大量のデータをそのまま扱おうとするとまだまだ限界がある。なるべく重要な情報が残るように、解像度が下がらないように工夫しながら、データをフィルタして集約して、最終的な目的に沿う形でLLMにインプットできるものに変換していくデータパイプラインをうまく設計する必要がある。
プロダクト用のデータパイプラインとか、分析用のデータパイプラインを作るだけじゃなく、開発生産性の向上用のデータパイプラインも必要なんだという新たな気づきを得ることができた。
おわりに
イベントが終わっての感想として頭に残ったのは、各セッションで話されている内容は、必ずしもAI Coding「だけ」に効果があるものではないなということ。
アーキテクチャや暗黙知を言語化してドキュメントしておくことや、それを継続的に最新の状態にメンテナンスし続けることは、LLMにとってもそうだけど、人間の開発者や組織にとってもとても嬉しいし必要なこと。
ソフトウェアを開発するという活動において、これらは本質的な必要な要素。開発のやり方はAIによってどんどん変わっていくけれども、これらの要素はなかなか陳腐化していかないはず。
新しいツールの登場や新機能のニュース、突然盛り上がるバズワードを追っかけるのはそれはそれで楽しい。なんだけれども、「何が本質的なのか」ということは見失わないようにしたい。できることが限られているスタートアップであるからこそ、そこに集中して投資をし続けていきたいなと思った。
Member discussion