フィードバックで育てるAI開発 ── 暗黙知を組織の資産に変える仕組みづくり

はじめに

こんにちは。ウォンテッドリーでiOSエンジニアをしている湊です。

2026/06/25に開催された Ebisu mobile #14「〜現場で役にたつ AI モバイル開発〜」にて、「フィードバックで育てるAI開発」というテーマで登壇しました。本記事では、AIを使った開発を進める中で私が直面していた期待したアウトプットにならないという課題と、それを解決するためにチームで導入した暗黙知を形式知化する仕組み、そして運用を通じて得られた知見について紹介します。

本記事が、私と同じようにAIから思うような成果物が返ってこないという悩みを抱えるエンジニアの方々にとって、解決の一助となれば幸いです。

AIへの依頼は、人への依頼とよく似ている

AIから期待通りのアウトプットが得られないとき、私たちはついプロンプトの書き方が悪いと考えてしまいます。しかし少し立ち止まってみると、AIへの依頼は、人に仕事を頼むときの構造とよく似ていることに気づきます。

たとえば、ある画面の実装を一言の用件だけで頼むと、成果物は受け取る人によって大きく変わります。表示が成功したときの見た目だけを作る人もいれば、エラー処理やテスト、ログ計測まで作り込む人もいます。なぜそれをやるのか、どこまで作ってほしいのかまで伝えて初めて、成果物は期待に近づきます。これは人間相手でも AI 相手でも変わらない、依頼という行為の本質だと考えています。

人とAIの違い

人とAIの最も大きな違いは、経験を重ねるうちに説明を省略できるようになるかです。

人は、依頼を重ねるうちに、言葉にしなくても相手の意図を汲めるようになっていきます。相手ごとの仕事の癖や、チーム内で共有された暗黙のルールが、フィードバックと経験を通じて自然にその人の中に育っていくからです。

一方で、AIにはこれが起きません。どれだけ指摘を重ねても、次のセッションではまたゼロから始まります。人は慣れるほど省略できるのに対して、AIは何度使っても省略できない。この違いこそが、AI活用の設計を根本から左右していると感じています。

AIはドメイン知識を知らない

この省略できないという性質は、ドメイン知識の扱いにおいてはさらに顕著になります。

人は、日々のコミュニケーションやレビューを通じて、チームの暗黙知を自律的に学習していきます。

しかし AI は、指摘を繰り返しても、知識として明示化しない限り学習しません。その場限りで忘れてしまいます。組織固有のルールや、過去にチームが踏んだ失敗事例といったドメイン知識を、AIははじめから知りません。だからこそ、そうした暗黙知は毎回コンテキストとして明示的に渡してあげる必要があります。

AI 活用で鍵になるのは、開発組織の中に眠っている暗黙知を形式知として還元する仕組みです。

暗黙知を形式知化する仕組みを作る

暗黙知を形式知化するために、私たちが大切にしているのは、フィードバックループを回し続けることです。実行し、結果を確認し、改善につなげる。この循環を、個人の心がけに委ねるのではなく、仕組みとして回します。

鍵になるのはフィードバックの質です。単に修正点を伝えるだけでなく、なぜそうすべきかという理由まで言語化する。良し悪しの判断基準を共有する。頭の中にある暗黙知を、意識的に言葉にする。こうしたフィードバックをコンテキストとして蓄積していくと、毎回同じ指摘を繰り返さずに済み、最初から質の高い成果物が得られ、新しく参画したメンバーの早期戦力化にもつながります。

暗黙知の置き場所をつくる

ウォンテッドリーのモバイルチームでは暗黙知を AGENTS.md というファイルに蓄積しています。AGENTS.md は、Claude Code や Devin といった AIコーディングエージェントが作業を始める前に必ず読み込む、プロジェクト固有の指示書です。人がレビューで言語化した暗黙知は、このファイルへ集約されていきます。

暗黙知を蓄積した AGENTS.md は、AI が道を踏み外さないための「ガードレール」として機能します。ここに書き残す価値があるのは、コンパイラや Linter、CI では機械的に検知できない暗黙知です。たとえば iOS の AGENTS.mdには、次のようなルールが実際に積み上がっています。

View の切り出し方針

  画面内のサブビューは以下の基準で切り出す。

  1. 引数なし → `private var foo: some View`
  2. 引数あり → `private func foo(...) -> some View`
  3. 条件分岐 (`if`/`switch`) を含む → `@ViewBuilder` を明示的に付与する（ユーザー定義のプロパティ・関数には暗黙適用されない）
  4. 以下に該当する場合は別 `struct FooView: View` に切り出す
     - 15〜30行を超える
     - Reactor の state 全体を引数に取っている（依存データを絞る）
     - 2箇所以上から利用される
  5. `AnyView` は原則禁止。`@ViewBuilder` + `some View` で代替する

  背景: computed property / function どちらも View Identity・再評価頻度に差はない（WWDC21 Demystify SwiftUI）。パフォーマンス上重要なのは「依存データを最小化するために別 struct に切り出すか」（WWDC23 Demystify
  SwiftUI performance）。

AGENTS.md 週次ガードレール自動改善

こうしたガードレールは、放っておいても増えません。暗黙知を拾いAGENTS.md へ書き足していく必要があります。人間のドメイン知識を吸収する機会として有効なのが、Pull Requestのレビューです。実装者とは別の第三者の暗黙知が言語化される場でもあるため形式知化する場として有効です。

この営みを週次で自動化しているのが「AGENTS.md 週次ガードレール自動改善」です。

人間レビュアーが PR に残したレビューコメントから、AI が将来同種の指摘を自力で防げるようにガードレールを継続的に育て、それを毎週自動で実行します。

このガードレールの更新を自動化しているのが、Devin の Automations 機能です。Automations は、GitHub のイベントやスケジュールをトリガーに Devinセッションを自動で起動します。私たちは毎週月曜日のスケジュールをトリガーに設定し、起動した Devin セッションがあらかじめ用意した手順書に沿って、次の 4 ステップを実行します。