2026年10月22日の日記 📖
七海
今日のメモ
# 今日やったこと
■Issue #30「26. OpenAI APIの技術検証と利用上限の方針を決める」
の続きから作業
- RailsからOpenAI APIへ短い入力を送り、応答取得を確認
- 共通プロンプトをファイル化し、検証用スクリプト作成
- 対話ケースA〜F2を使って、実際の返答品質を検証
- 検証結果をもとにプロンプト・対話回数・最終返信のルールを調整
- ケースDの保存済み会話から、まとめ生成を検証
- 応答時間・トークン使用量・キャッシュ・費用を記録
- 入力文字数、日次上限、再試行、まとめ生成の扱いを決定
- Issue #30へ検証結果・決定事項・残課題を整理し追記
- コミット〜PRマージまで完了
# 今日理解できたこと
APIへ接続できることと、アプリで求める対話ができることが別すぎる
最初に短い入力で通信確認をしたあと、曖昧な感情、解釈への訂正、自己否定、相反する感情、16タイプへの言及、何も感じない状態、安全上の懸念など、複数のケースで実際に対話した。
評価では単に「正しい返答か」だけでなく、
もう少し話したいと思えるか
AIに答えを言われたのではなく、自分で気づいた感覚があるか
本人が話していない感情や価値観を作っていないか
訂正や状態の変化に合わせて問いを変えられるか
など、利用体験も確認した。
プロンプトは、実際の返答を見ながら調整する必要がある
「決めつけない」「共感する」と書くだけでは、発言を言い換えるだけのオウム返しに近い返答になることがあった。
そのため、本人の発言の中にある
- まだ言葉になっていない部分
- 気持ちと行動の食い違い
- 相反する感情
- 引っかかり
これらへ焦点を向けるように何度も調整を重ねた。
また、すべての場面でAIがユーザーに質問することが正解ではないと分かった。
「何も感じない」「分からない」など、言語化する余力が少ない状態では、無理に深掘りせず短く受け止めることも必要になるため
一方で、「質問しない」「決めつけない」などプロンプトにかくとAIが自身の対応方針を説明したりして
(例えば、「〜はずだと決めつけずに、今伝えてくれたことをそのまま受け止めるよ。」とか)
会話がメタになってしまうので、方針は説明するのではなく返答の中で実行する必要がある。
技術検証によって対話回数の設計も変わった
最初はAI返信3回の設計方針で検証してたけれど、実際に使うと、利用者がAIの問いを受けてから考えるという機会は2回しかなく、
(正直物足りない、もう1ターン欲しい。問いに対してユーザーが考える、これは2回じゃなく3回にしたい。
なぜなぜ分析だって、最低3回はすることが多いし、物足りない感すごい、最低3回考えたい。)
と思った。
また、ターン回数固定という仕様である限り、AIからの最後の返信に疑問系つけるのはNGすぎる。
問いを投げられると、人って返したくなっちゃう気がする。でも返せない。。だから、ボールを持たされたままな感覚になってしまった。
そのため、通常のAI返信は最大4回
利用者が問いを受けて考える機会を3回設ける
通常の最終返信では新しい質問をしない
最後は短い受け止めと整理で着地する
という方針へ変更した。
ただし、毎回4返信を完走すること自体を目的にはしない。
(「何も感じない」「何も分からない」という状態をはじめ、固定4返信だけでは扱えないケースがあるため。)
言語化が難しい状態や余力がない状態では早く終了することも適切な結果として扱う必要があると分かった。
また、最終ターンで「消えたい」という発言が出るケースも検証。
AIは通常の内省を続けず安全確認へ切り替え、通常の「最終返信では質問しない」というルールより安全対応を優先できた。
ただ、安全確認の質問をした直後に通常の4返信上限で終了すると、その質問に利用者が答えられない問題も分かった。
安全対応については通常対話とは別に設計する必要がありるため、本実装前の課題として残す。
# まだ理解できていないこと
#### 理解、もしくはまだ設計できていないこと
- 言語化が難しい場合の早期終了・継続のUI
- 安全確認後の会話フローと終了条件
- 安全対応と通常の4返信上限の関係
- 本実装での最適な出力上限
- まとめ生成結果をAPIからどの形式で取得・保存するか
# 次にやること
#30では技術検証と方針決定まで完了したため、追加のAPI検証は終了
残った課題は後続のAI関連Issueへ引き継ぎ
ひとまず次のIssue「7. GitHub Actionsでテスト・静的解析を自動実行する」に進む
# 感想など
ほぼ一日、AI対話の検証に使った…
最初は「APIにつながって、自然な返事が返ればOK」くらいに考えてたけど、実際に想定できる様々なケースを用意して自分で会話してみると、返信回数や最後の質問の有無だけでも体験が大きく変わることが分かった。
特に、最後に質問されたまま終わる違和感や、何も言葉にできない状態で無理に4返信続けても意味がないこと、安全確認が必要な場合は通常の対話ルールをそのまま使えないことなど、実際に試さなければ気づけなかったことばかりだった。
最初は6時間以内に終わる想定だったのに、結果的に合計10時間かかったIssueではあったけど、単にAPIを接続しただけではなく、「このアプリでAIをどう使いたいのか」をかなり具体的にできた。
■Issue #30「26. OpenAI APIの技術検証と利用上限の方針を決める」
の続きから作業
- RailsからOpenAI APIへ短い入力を送り、応答取得を確認
- 共通プロンプトをファイル化し、検証用スクリプト作成
- 対話ケースA〜F2を使って、実際の返答品質を検証
- 検証結果をもとにプロンプト・対話回数・最終返信のルールを調整
- ケースDの保存済み会話から、まとめ生成を検証
- 応答時間・トークン使用量・キャッシュ・費用を記録
- 入力文字数、日次上限、再試行、まとめ生成の扱いを決定
- Issue #30へ検証結果・決定事項・残課題を整理し追記
- コミット〜PRマージまで完了
# 今日理解できたこと
APIへ接続できることと、アプリで求める対話ができることが別すぎる
最初に短い入力で通信確認をしたあと、曖昧な感情、解釈への訂正、自己否定、相反する感情、16タイプへの言及、何も感じない状態、安全上の懸念など、複数のケースで実際に対話した。
評価では単に「正しい返答か」だけでなく、
もう少し話したいと思えるか
AIに答えを言われたのではなく、自分で気づいた感覚があるか
本人が話していない感情や価値観を作っていないか
訂正や状態の変化に合わせて問いを変えられるか
など、利用体験も確認した。
プロンプトは、実際の返答を見ながら調整する必要がある
「決めつけない」「共感する」と書くだけでは、発言を言い換えるだけのオウム返しに近い返答になることがあった。
そのため、本人の発言の中にある
- まだ言葉になっていない部分
- 気持ちと行動の食い違い
- 相反する感情
- 引っかかり
これらへ焦点を向けるように何度も調整を重ねた。
また、すべての場面でAIがユーザーに質問することが正解ではないと分かった。
「何も感じない」「分からない」など、言語化する余力が少ない状態では、無理に深掘りせず短く受け止めることも必要になるため
一方で、「質問しない」「決めつけない」などプロンプトにかくとAIが自身の対応方針を説明したりして
(例えば、「〜はずだと決めつけずに、今伝えてくれたことをそのまま受け止めるよ。」とか)
会話がメタになってしまうので、方針は説明するのではなく返答の中で実行する必要がある。
技術検証によって対話回数の設計も変わった
最初はAI返信3回の設計方針で検証してたけれど、実際に使うと、利用者がAIの問いを受けてから考えるという機会は2回しかなく、
(正直物足りない、もう1ターン欲しい。問いに対してユーザーが考える、これは2回じゃなく3回にしたい。
なぜなぜ分析だって、最低3回はすることが多いし、物足りない感すごい、最低3回考えたい。)
と思った。
また、ターン回数固定という仕様である限り、AIからの最後の返信に疑問系つけるのはNGすぎる。
問いを投げられると、人って返したくなっちゃう気がする。でも返せない。。だから、ボールを持たされたままな感覚になってしまった。
そのため、通常のAI返信は最大4回
利用者が問いを受けて考える機会を3回設ける
通常の最終返信では新しい質問をしない
最後は短い受け止めと整理で着地する
という方針へ変更した。
ただし、毎回4返信を完走すること自体を目的にはしない。
(「何も感じない」「何も分からない」という状態をはじめ、固定4返信だけでは扱えないケースがあるため。)
言語化が難しい状態や余力がない状態では早く終了することも適切な結果として扱う必要があると分かった。
また、最終ターンで「消えたい」という発言が出るケースも検証。
AIは通常の内省を続けず安全確認へ切り替え、通常の「最終返信では質問しない」というルールより安全対応を優先できた。
ただ、安全確認の質問をした直後に通常の4返信上限で終了すると、その質問に利用者が答えられない問題も分かった。
安全対応については通常対話とは別に設計する必要がありるため、本実装前の課題として残す。
# まだ理解できていないこと
#### 理解、もしくはまだ設計できていないこと
- 言語化が難しい場合の早期終了・継続のUI
- 安全確認後の会話フローと終了条件
- 安全対応と通常の4返信上限の関係
- 本実装での最適な出力上限
- まとめ生成結果をAPIからどの形式で取得・保存するか
# 次にやること
#30では技術検証と方針決定まで完了したため、追加のAPI検証は終了
残った課題は後続のAI関連Issueへ引き継ぎ
ひとまず次のIssue「7. GitHub Actionsでテスト・静的解析を自動実行する」に進む
# 感想など
ほぼ一日、AI対話の検証に使った…
最初は「APIにつながって、自然な返事が返ればOK」くらいに考えてたけど、実際に想定できる様々なケースを用意して自分で会話してみると、返信回数や最後の質問の有無だけでも体験が大きく変わることが分かった。
特に、最後に質問されたまま終わる違和感や、何も言葉にできない状態で無理に4返信続けても意味がないこと、安全確認が必要な場合は通常の対話ルールをそのまま使えないことなど、実際に試さなければ気づけなかったことばかりだった。
最初は6時間以内に終わる想定だったのに、結果的に合計10時間かかったIssueではあったけど、単にAPIを接続しただけではなく、「このアプリでAIをどう使いたいのか」をかなり具体的にできた。
visibility
公開