S&Pの社内会議を、ほぼそのまま書き起こしてみます。

うちの会社の会議は、たぶん想像されているものとは少し違います。

「AI活用を推進します」みたいな話は出てきません。出てくるのは、もっと手前の、もっと具体的な話です。今日はそのサンプルとして、ある日の定例をほぼそのまま書き起こしてみたいと思います。

議題は、自社サービスのテスト自動化。地味です。ですがこの会議の後半で、「AI専用の会社を一社作る」という結論が出ました。

発端は「自分のブラウザを使いたくない」でした

口火を切ったのはエンジニアAでした。

ブラウザ操作の自動テストを検証していて、方針が固まったとのこと。自分のChromeを使うのではなく、Claude Cowork内のサンドボックス化されたブラウザ環境でやる、という提案です。

代表とクラウドエンジニアがすぐに確認したのは認証情報の扱いでした。自動化するということは、どこかでログインが発生します。そこに何のアカウントを使うのか。

Aの答えは、独立したテストユーザーを用意して、ログイン情報は手動で入力する、というものでした。

代表がここで「ああ、メールのときと同じか」と言いました。うちではCoworkを使ってメール送信も自動化していて、そのときの運用と構造が同じだと気づいたようです。

こういう横の接続が早いのは、全員が手を動かしているからだと思います。

「削除を徹底」から「常駐させる」への転換

次にクラウドエンジニアが出したのは、運用面の指摘でした。

テストが終わったらそのユーザーは確実に削除すべきだ、と。インターネットからアクセスできる以上、テスト用アカウントが残り続けるのはリスクになります。

ここでAが、面白い返し方をしました。

削除するのではなく、最も低い権限の一般ユーザーとしてアカウントを作り、AI専用ユーザーとして常駐させてはどうか。そうすれば自動化テストを継続的に回せる、と。

代表もクラウドエンジニアも、この案に乗りました。ただし条件がつきます。管理画面の操作のような、システムの根幹に関わるテストは一般ユーザー権限の範囲外とする。つまりテスト項目そのものを権限で切り分けるということです。

クラウドエンジニアからはもう一点、IDとパスワードは推測されにくいものにすること、という指摘が入りました。代表がそれを受けて留意事項として確認します。

提案が出て、リスクが指摘され、代案が出て、条件付きで合意される。ここまで数分でした。

「株式会社テスト」

そしてAが、この日のハイライトになる構想を出しました。

AI専用の組織アカウントを作る。仮に「株式会社テスト」としましょう。そこで人材のやり取りも、教材配信も、全部AI同士にやらせる。

本番環境の中に、誰も傷つかない一社を置くという発想です。実在する顧客企業には一切影響を出さないまま、実際のシステム上でバグを抽出できます。

代表とクラウドエンジニアはこのアイデアを高く評価しました。クラウドエンジニアからは配置についての補足があります。隔離するのではなく、他の顧客企業と水平方向に並べる形で置くべきだ、と。

代表が引き取ってこう言いました。まずMVPとして作って、AIに継続的にテストさせる。そこで検出されたバグの解析結果を、システムに反映していく。

「ログを読ませればいい」

クラウドエンジニアが、この手法が有効である理由を一言で説明しました。

動作の大部分はログに現れる。だからログを読ませて正常性を判別させれば、バグの検知は十分に成立する、と。

代表はもう少し引いた視点から言いました。本来は人間がやっていたテスト検証をAIに代替させることで、バグを事前に吸収できる。組み込み系の案件でも自動化・内製化を進める動きがあるし、これは時代の流れに沿った試みだ、と。

うちが受託と自社開発の両方をやっていることが、こういうところで効いてきます。よその現場で起きている変化が、自社プロダクトの意思決定に直接入ってくるからです。

途中から入ってきた人が、現実を持ち込む

会議の後半、もう一人のエンジニアBが途中参加しました。そして話を聞くなり、実務的な懸念を出します。

自動テストではブラウザごとのJavaScriptの挙動差が問題になる。特にSafariは独特な動きをするし、カレンダー表示の不具合なども起きる。モバイル対応時はどうするのか。Chromiumベースの環境でどこまで担保できるのか、確認が必要だ、と。

止めにきたわけではありません。新しい機能テストの試みとしては賛同を示した上で、見落とされそうな穴を先に指摘してくれました。

遅れて入ってきた人がその場で議論に割り込んで、論点を一つ増やす。誰も気を悪くしません。うちの会議はだいたいこういう感じで進みます。

この日の合意

この会議で決まったのは、二つでした。

Claudeのサンドボックスブラウザを使ったテスト自動化を、権限を一般ユーザーの範囲に限定して導入すること。そして、受講生の質問データから「どこでつまずいているか」を可視化する機能を新たに作ること。

後者はAが「管理者の手を介さずに一目で分かるようにしたい」と言い出したものです。代表が賛同し、実習の次の段階としてマニュアルの組み込みまでやりたいと応じました。

最後に、代表がこう締めました。

こうした自動化の相談や実践は、自社のノウハウとして蓄積していくべきものだ。先んじて新しい枠組みを取り入れていくことに意味がある、と。

その後、参加者全員でリリース判定の文章を確認し、問題なしという合意に至りました。リリース文章が送信されて、会議は終わりました。

なぜこれを公開するのか

派手な話ではありません。テストアカウントの権限をどうするか、という話です。

ただ、AI駆動開発という言葉が指しているものの実態は、たぶんこういうところにあります。コードを速く書くことではなく、「テストを人間がやる前提」そのものを疑って、設計をやり直すこと。

そしてその判断は、会議室で数分のうちに下されます。提案する人がいて、リスクを指摘する人がいて、代案を出す人がいて、遅れて入ってきて穴を突く人がいる。役職も年次も、ほとんど関係ありません。

S&Pに興味を持ってくださった方には、こういう場に入ってもらうことになります。

こんな会議に混ざってみたい方、お待ちしています。

https://www.wantedly.com/projects/2446533