「誰のAIが、何をしたか」を追えるように。Tumikiのプロダクト設計

こんにちは、株式会社RAYVEN採用担当です。

前回までの記事で、Tumikiが生まれた原点と、「AIを禁止しない」というRAYVENの考え方をお伝えしました。最終回となる今回は、その考え方が実際のプロダクト設計にどう落とし込まれているかをご紹介します。

前回記事はこちら「禁止でも放任でもない。RAYVENが考える、AIとの付き合い方」

三つの機能：マスキング・権限制御・記録

Tumikiの中心となる機能は、大きく三つに整理できます。

一つ目は、個人情報のマスキングです。AIがデータを取得するタイミング、あるいはAIが外部にデータを送信するタイミングで、個人情報などをマスキングし、外部への漏洩を防ぎます。

二つ目は、権限の制御です。AIに持たせる機能そのものを制限し、必要以上の権限を渡さないようにします。

三つ目は、記録です。AIが何を行ったのかを、後から追える形で残しておきます。

これに加えて、従業員一人ひとりが、AIモデルそのものに依存するのではなく、自分に付与されたツールやデータへ、AI経由でアクセスするという構成も、設計の重要な部分になっています。

「誰のAIが、何をしたか」を追える設計

この三つの機能を支えるのが、「誰のAIが、何をしたか」を追跡できる設計です。

考え方としては、Microsoft、Google、Oktaといった、企業が既に使っているID基盤と従業員を紐づけ、どの従業員のどのAIツールが、どの社内ツールへアクセスしたかを記録します。誰がその利用を承認したのかも、証跡として残す。AIエージェントごとに使える機能を制限し、SaaSとの接続もOAuthを介して行うことで、特定のAIモデルに依存しない構成を目指しています。

こうした設計思想は、複数の商談の場で語られてきたものですが、あくまで検討・提案段階の内容を含んでいます。実際にどこまでが現行の実装として提供されているかは、この記事の公開前に改めて確認が必要です。

非エンジニアに、JSONは触らせない

Tumikiの設計でもうひとつ大切にしているのが、非エンジニアでも扱える導入体験です。

ある企業の担当者からは、AI関連の問い合わせ対応の負荷の高さについて、率直な声をいただいたことがあります。非エンジニアがTOMLやJSONのような設定ファイルを直接編集する運用は、現実的ではありません。ツールをカタログから選んで追加できる仕組みや、トークンの利用状況をコントロールできる仕組みが必要だ、というご指摘でした。

これに対してRAYVENが目指しているのは、非エンジニアにJSONファイルを直接触らせない設計です。デスクトップアプリの画面上で設定を完結させ、管理者側からは利用状況を監視できるようにする。ドキュメントツールであれば、閲覧のみ、編集可能、といった権限も細かく制御できるようにする。管理者と一般の従業員との間にあるAIリテラシーの差を、仕組みの側で埋めていく、という発想です。

「壮大な話」より、具体的な一場面を

プロダクトを説明する中で、印象に残っているフィードバックがあります。

ある商談で、こちらの説明が壮大に聞こえすぎている、というご指摘をいただいたことがありました。営業活動全体のような広いテーマではなく、たとえばGitHubとJiraを使った開発・運用のような具体的な場面に絞って、Tumikiを使うことで何がどう良くなるのかを示してほしい、というものです。

このフィードバックは、Tumikiというプロダクトを説明する上で、大切な学びになりました。機能を網羅的に並べるのではなく、一つの具体的な利用場面を軸に、そこで何が変わるのかを丁寧に伝えること。これは、プロダクトの説明の仕方だけでなく、RAYVENが顧客の課題にどう向き合うかという姿勢そのものにも通じる話だと感じています。