Kotone Local Applicationでは、個別支援計画、日々の支援、
ケース記録、振り返りを、意味を失わずにつなげる仕組みを目指しています。
第0回では、なぜこのApplicationを作ろうと考えたのか、
その出発点について紹介しました。
目的が見えてきたあと、次に行ったのは実装ではありませんでした。
AIを使えば、以前よりもずっと速くSoftwareを作ることができます。
だからこそ最初に考えたのは、
「このApplicationは、何を事実として扱ってよいのか」
という問題でした。
AIを使えば、コードは速く作れる
現在は、ChatGPTやCodexのようなAIを使うことで、
Software開発の多くの作業を支援してもらえます。
例えば、
- 画面を作る
- Databaseを設計する
- 入力内容を保存する
- 処理を実装する
- Testを書く
- コードを修正する
といった作業です。
以前なら時間のかかっていた実装も、
AIを使うことで大幅に速く進められるようになりました。
Kotone Local Applicationの開発でも、
AIを設計の整理や検討に活用し、
実装でもAI Coding Agentを利用していく予定です。
それでも、最初に、
「このApplicationを作って」
と依頼することはしませんでした。
理由は、コードを書く速度が上がっても、
何を作るべきなのかが正しくなるわけではない
からです。
「選択できた」という記録は、それだけで十分なのか
例えば、完全に架空の場面を考えてみます。
ある活動の中で、本人がすぐには選択を示しませんでした。
そこで支援者が二つの選択肢を提示したところ、
その後、一方を選びました。
この出来事だけを見れば、
「選択できた」
と記録することができます。
しかし、それだけでは一つ重要な情報が消えています。
二つの選択肢が提示されたあとに成立した。
結果だけではなく、その結果がどのような条件の中で成立したのかも、
次の支援につながる重要な情報です。
もしSoftwareが、
「選択できた」という結果だけを保存すれば、
次に記録を見る人には、
- 自分から選択したのか
- 選択肢が提示されたのか
- どの程度の支援が必要だったのか
が分からなくなります。
同じ「できた」という言葉でも、
その中身は同じとは限りません。
「できなかった」も簡単には決められない
反対に、ある日の記録に
選択する行動が書かれていなかったとします。
だからといって、
「選択できなかった」
と判断できるとは限りません。
その日は選択する場面がなかったかもしれません。
記録されなかっただけかもしれません。
活動や環境が違っていたかもしれません。
判断するための情報が十分ではなかった可能性もあります。
確認できなかったことと、
できなかったことは同じではありません。
分からないものを、
Softwareの都合で「失敗」や「未達成」に変えないことも、
今回の設計で大切にしている点です。
Softwareにとっては、
空欄を「未達成」に変換した方が処理しやすいかもしれません。
しかし、それを行うと、
Softwareの都合によって本人の姿が変わってしまいます。
そのためKotone Local Applicationでは、
「分からないものは、分からないまま残せること」
も重要だと考えています。
起きたことと、そこから考えたことを分ける
もう一つ重要になったのが、
事実と解釈を分けることです。
例えば、
「本人が『いや』と伝えた」
という記録があります。
これは、その場で確認された出来事です。
一方、
「予定が変わったことが嫌だったため拒否した」
という説明はどうでしょうか。
十分にあり得る解釈かもしれません。
しかし、実際に確認された出来事と、
そこから考えた理由は同じではありません。
「起きたこと」と「そこから考えたこと」を分ける
現実の場面
支援の中で
出来事が起きる
観察
実際に確認できた
内容を残す
事実
起きたことを
事実として整理する
解釈
事実から考えられる
意味を分けて扱う
人が確認
内容を確認し
次の検討につなげる
AIは、このような情報を自然な文章として
つなげることが得意です。
そのため文章として読むと、
「本人は予定変更が苦手なので拒否した」
という一文が、とても自然に見えることがあります。
しかしSoftwareに保存するときには、
確認されたことと
そこから考えられることを
分ける必要があります。
自然な文章であることと、
確認された事実であることは同じではありません。
支援の条件を消さないために
第0回でも触れたように、
本人の姿は環境によって変わります。
同じ活動でも、
- 人
- 場所
- 声かけ
- 見本
- 選択肢
- 活動の長さ
- 見通し
- 周囲の人数
などによって、成立しやすさが変わります。
そのため、
「できた」という結果だけを保存するのではなく、
どのような条件の中で、その出来事が起きたのか。
を一緒に保持する必要があります。
これは、細かな記録を増やしたいからではありません。
次に同じ場面を支援するとき、
「何が通りやすさにつながっていたのか」
を確認できるようにするためです。
Databaseを作る前に、意味の境界を考えた
通常のApplication開発では、
早い段階でTechnologyを選ぶことがあります。
どの画面技術を使うのか。
どのDatabaseを使うのか。
どのように情報を保存するのか。
Kotone Local Applicationでも、
現在はWindows上で動くLocal Applicationとして
開発を進めています。
しかし、それより前に考えたのは、
- 何を元の記録として残すのか
- 何を観察された事実として扱うのか
- 何を解釈として扱うのか
- 何がまだ確認できていないのか
- 誰が最終的に確認するのか
- 後から元の記録へ戻れる必要があるのか
ということでした。
Databaseの構造を決める前に、
情報の「意味の境界」を決める。
何を保存するかだけではなく、
保存された情報が何を意味するのかを先に整理しました。
AIを使うからこそ、境界を先に決める
AIはとても便利です。
条件を与えれば、
一般的に合理的と思われる構造を提案してくれます。
例えば、
- 似た情報をまとめる
- 不要に見える項目を減らす
- 処理を簡単にする
- 自動化できるところを自動化する
といったことです。
Software開発では、
こうした合理化が有効なことも多くあります。
しかし今回のApplicationでは、
合理化によって、
支援上必要な意味まで消えてしまう可能性
があります。
例えば、
「人が確認した」という状態を
一つのチェック欄だけで表現すれば、
Softwareとしては簡単です。
しかし、
- 誰が確認したのか
- 何を確認したのか
- どこまで確認したのか
- 修正したのか
- 判断を保留したのか
まで必要なら、一つのチェック欄では足りません。
AIに実装を任せる前に、
簡略化してはいけない意味は何か
を決めておく必要があります。
AIを使うのに、AIを必須にはしない
Kotone Local Applicationでは、
AIを開発に活用しています。
将来的にはApplicationの中でも、
情報整理や候補の作成などに
AIを利用する可能性があります。
一方で、基本的な流れは、
AIやInternetがなくても成立する。
方向で設計しています。
これはAIを使わないという意味ではありません。
AIにしかできないことと、
AIがなくても成立させるべきことを
分けるためです。
また、AIが候補を提示した場合でも、
その内容をそのまま正式な判断として確定するのではなく、
人が確認し、採用・修正・判断する。
AIは判断そのものを引き受けるのではなく、
人が考えるための支援を行う。
この境界も、コードを書く前に整理しています。
速く作ることと、急いで作ることは違う
AIによって、
Software開発の速度は大きく上げられます。
これは大きな利点です。
一方で、設計が曖昧なままなら、
間違った意味を持つSoftwareも、
同じ速度で作れてしまいます。
そのためKotone Local Applicationでは、
「まず動くものを作る」ことよりも、
- 何を事実として扱うのか
- どこまで推測してよいのか
- 何をSoftwareが自動的に確定してはいけないのか
- 誰が最終的に確認するのか
- その判断の根拠まで戻れるのか
を先に整理しました。
AIを使うからこそ、最初にコードを書かなかった。
これは、Kotone Local Applicationの開発で
最初に行った大きな設計判断です。
現在地
現在、Kotone Local Applicationは、
基本的なApplication Architectureや情報の扱い方、
実装時に守るルールなどを整理し、
本格的な実装へ進む段階にあります。
まだApplicationが完成したわけではありません。
これから実際の実装を行い、
まずは個人を特定しない架空の検証用データを使って、
設計した意味や境界を、
Softwareの中でも本当に守れるのか
を確認していきます。
設計したから正しいとするのではなく、
実装後のTestを通して検証していく予定です。
