この投稿は、JINS Advent Calendar 2025 の 13日目 の記事です。
時間がない方はこちらの画像をご確認ください
自己紹介
JINSでプロジェクトマネージャーをしているカニです。
JINSには2025年6月に入社しました。右も左もわからないわけではないですが、まだ不慣れなことばかりです。
その中で何とかかんとか皆様のご協力を得ながら、プロジェクトを前に進める仕事をしています。
プライベートでは、全然懐いてくれないミニチュアシュナウザーと暮らしています。「飼っている」というよりは、「ルームシェアしている」感覚に近いです。
生成AI使っていますか？
この記事を読んでいる皆様は、おそらく日々の業務で生成AIを使っているのではないでしょうか。弊社内でも「生成AIの活用」が推進されています。
私自身も日々の業務の中で少しずつ生成AIを使っています。
- 要件定義ドキュメントのレビュー
- スプレッドシート関数の書き方の確認
- 日々の悩み相談
もっと活用の範囲を広げていきたいと考えています。
そんな生成AIブームの昨今、ふと思ったことがあります。
それは「生成AIの前に内なるAIを活用しないとだめではないか？」ということです。
内なるAIとは
「内なるAI」とは何か。ググっても出てきません。これは私自身が勝手に考えた言葉だからです。
「内なるAI」とは人間に備わっているAIのことを指します。
例えば「愛（AI）」だったり、「思いやり（OMOIYARI）」だったり、「おせっかい（OSEKKAI）」だったりします。
内なるAI活用の事例
じゃあ、「内なるAI」を活用するとは一体何なのか。
私自身が実践していたり、実際に直面したりした事例を挙げてみます。
どれも、文字にしてしまうと当たり前だったり、些細だったり、少し冗長に感じられることかもしれません。
MTGのアジェンダの事前提示
『MTGは事前準備が大事』というのは、あちこちで言われていますし、その通りだと思います。
MTGの目的を定義し、そのための準備をする。MTGの目的を達成するという合理的な理由から必要なことです。
一方で、『準備した内容を事前に提示すること』は、私は『内なるAI』の活用だと考えています。
なぜなら、事前に提示されたアジェンダがあることで、参加者は自分の行動を選択できるようになるからです。
- 事前調査など材料集めを行える
- 内容によってはMTGを待たずにチャット等非同期のコミュニケーションで解決できる
- 参加不要と判断し、議事録でのキャッチアップを選択できる
その結果、MTGに招待された人は、自分の時間の使い方を自分でコントロールできるようになります。
チャットでの事例
チャットでの事例として、このようなやり取りがあったとします。
- AさんがAPI仕様を作成し、Bさんに確認依頼を投げた
- Bさんは様々な変更箇所を伝え、Aさんはそれを修正した
- 修正後、AさんはBさんに再レビューの依頼を投げて、更にCさんにも確認依頼を投げた
やり取りの時系列は、以下のようなイメージです。
| 時刻 | 送信者 | 内容 |
|---|---|---|
| 10:00 | A | API仕様書を作成したのでレビューお願いします。https://example.com/hoge |
| 13:35 | B | 確認します。まず、GET /users/{user_id} のレスポンスフィールドについてですが、user_idは文字列でしょうか？仕様書では型が明記されていませんでした。 |
| 14:15 | A | ご指摘ありがとうございます。user_idは整数です。仕様書を修正しておきます。 |
| 16:02 | B | 承知しました。次に、POST /items のリクエストボディについてですが、priceフィールドの最小値・最大値の制約はありますか？ |
| 16:40 | A |
priceは1から1,000,000の範囲でお願いします。 |
| 17:50 | B | ありがとうございます。認証方法についてですが、全APIでBearer Token（JWT）で合っていますか？ |
| 18:30 | A | はい、その通りです。 |
| 10:05 (翌日) | B |
PUT /items/{item_id} のリクエストボディにある description フィールドは、必須項目でしょうか？ |
| 10:45 (翌日) | A | いいえ、descriptionは任意項目です。nameは必須です。 |
| 12:15 (翌日) | B | エラー時のレスポンス形式は、仕様書にある通り、HTTPステータスコードに加えてJSONボディでerror_codeとmessageを返す形式で統一されていますか？ |
| 12:40 (翌日) | A | はい、全てのAPIでその形式を適用しています。 |
| 14:30 (翌日) | B | レートリミットについてですが、現在の設定だと高頻度のアクセスがあった場合に問題になる可能性があります。エンドポイントごとの制限値はもう少し緩和できませんか？ |
| 15:00 (翌日) | A | どのエンドポイントの制限を調整したいか教えていただけますか？ |
| 16:10 (翌日) | B | 特に GET /items のリスト取得APIです。現行の「100回/分」を「300回/分」に上げたいです。 |
| 16:45 (翌日) | A | 承知しました。レートリミットの設定を見直します。 |
| 17:50 (翌日) | B | その他、細かい点ですが、仕様書内の誤字を2点ほど見つけました。（「リクススト」→「リクエスト」など） |
| 18:20 (翌日) | A | 修正しました。レビューお願いします。 |
| 18:25 (翌日) | B | レビューOK。 |
| 18:30 (翌日) | A | Bさんにレビューしていただきました。Cさんも念の為ご確認お願いします。 |
想像してみてください。あなたがCさんだったら、どう感じるでしょうか。
- 何を確認すれば良い？
- ここまでの長いやり取りで、結局『何が』変わったの？
- この確認は、どのくらいの精度でやるべき？
では、『内なるAI活用』という観点で、Aさんは何をすべきだったのでしょうか。
- 確認対象のURLを再掲する
- Bさんとのやり取りでの変更点をまとめる
- 確認の観点を伝える
等々。
こうしたひと手間をかけることで、Cさんの確認コストを大きく下げることができます。
このひと手間が『内なるAI活用』と考えます。
生成AIと内なるAI
内なるAI活用の事例を2つ紹介しました。
特に後者は手間のかかることをやっている印象を持たれたかもしれません。
URLの再掲や、やり取りの要約を書くことは、確かに手間ですし冗長にも見えます。
ただ、人間同士のやり取りには『念のため』や『リマインド』といった言葉があるように、ある程度の冗長さはとても大切だと思っています。この冗長さによって他者の時間の効率化を実現します。
これらの冗長さは、生成AIを使うことで効率よく実現できます。
…
生成AIによって浮いた時間と余裕で、内なるAIを発揮し、他者の時間の効率化に貢献する。つまり、内なるAIを発揮するためには、まず自分の時間を生成AIで効率化して確保することが不可欠だ、ということです。
そして私の内なるAIで効率化した誰かの時間が、更に内なるAIを発揮して誰かの時間を効率化する。
つまり「愛には愛で感じ合おうよ」ということです。
Discussion