AIを敬意を持って使用するためのガイドライン
企業がAIツールを採用する中で、リーダーはセキュリティやコンプライアンスだけでなく、チーム内での敬意あるAI利用に関するガイドラインを策定する必要があります。主要な原則：自分が読んでいないものを他人にレビューさせない、AI出力は簡潔に保つ、AIは思考や心をオフにする言い訳ではない。ガイドラインを企業価値観に結びつけることで受け入れられやすくなります。
以下はMediumに掲載された記事であり、著者の許可を得て転載しています。
企業がAIツールを採用するにつれて、セキュリティ、コンプライアンス、さらにはコストに焦点を当てたAIポリシーを考えることに多くの時間が費やされています。しかし、多くのリーダーは、チーム全体の文脈でどのようにAIを活用すべきかという点に対処することを怠っています。これにより、多くの未解決の緊張が生じており、リーダーは「承認された」方法でAIを使用する方法だけでなく、敬意を持って使用する方法についてのガイドラインを設定する時が来ています。
私が「敬意を持って」と言うとき、基本的な適切な職場行動（いじめ、虐待、嫌がらせなど）を指しているのではありません。むしろ、AIが個人の生産性を向上させる方法（文字通りより多くのアウトプットを可能にする）が、チーム全体の生産性に悪影響を及ぼす可能性があることを、私たちの多くが考慮していないことを懸念しています。リーダーは、チームがただ質の低いものを生産して他者に送るだけではないと期待して座っているわけにはいきません。まだ徹底したポリシーを設定していない場合、ここにカバーすべき提案をいくつか示します。
敬意あるAI使用の要素
自分が読んだりレビューしていないものを他人に読んだりレビューさせない。
これは、AI重視のチームで働く人々から最もよく聞かれる不満の1つです。コードの所有者がレビューのために提出する前に実際に理解していなかったコードであれ、生成しただけで読んでいない文書であれ、あまりにも頻繁に、人々は自分の作業を効率化しながら同僚にすべての品質管理を任せることで、同僚から生産性を盗もうとしています。AIコード生成→AIコードレビュー→AI修正→最終的な人間によるレビューのループは素晴らしいですが、AIにプロンプトを送る人がそのコードを最初にレビューしなければ、チームメイトに大きな検証負担を課すことになります。チームメイトは、あなたのプロンプトが適切であること、そしてAIがコンテキストと問題を十分に理解して持続可能なソリューションを得たことを信頼しなければなりません。
文書はコードよりもさらに誘惑的です。なぜならAIは非常に冗長で、私たちのほとんどが執筆と編集を嫌うからです。AIにいくつか質問し、回答をざっと読み、文書を出力して他の人に送るというループに陥りやすくなります。私自身もこれに罪悪感があります！しかし、一度に一つの回答をざっと読むときに意味があることが、全体的な文書として良いとは限らず、個々の質問に答えることと人間の読者のために書くことには大きな違いがあります。特に、AIと話しているときに頭の中にあるコンテキストは文書にまったく現れないかもしれません。送信する前に徹底的に読まなければ、フレーミングのギャップに気づかないでしょう。
さらに悪いことに、時には人々は自分がプロンプトした文書が何を言おうとしているのかさえ理解していません。この文書を説明し、他の人とその概念について会話し、なぜそれが理にかなっているのかを議論できますか？そうでなければ、少なくとも「これはAI生成であり、私はまだこの分野をよく理解していません。助けてください」という大きな警告なしに送るべきではありません。
多くの人は、自分で書いてもいないものを読まないという段階に達しています。多くの人が送信前に自分の出力さえ読まない現状では、彼らを責めることができるでしょうか？
短い方が良い。
AI生成作品のレビューの煩わしさの一部は、AIが非常に長ったらしくなることです。AIコードはチュートリアルコードのように見え、人間の開発者がわざわざ書くよりもはるかに冗長です。さらに、変更を小さな断片に分割する方法を考えるのではなく、一度に大きな変更を行いたいという誘惑が加わり、千行のプルリクエストの山ができあがります。AIが生成する文書は非常に徹底しているため、3ページで済むはずのものが10ページや20ページになります。そして、すべてのテキストベースのやり取りにAIを完全に取り入れた人々は、LLMが生成した壁のようなテキストのチャットメッセージやメールを見始めます。
これは、率直に言って失礼です。それは自分の作業をレビューしないことと密接に関連していますが、何らかの理由でその巨大なPR/文書/メッセージを実際に読んで編集したと自分に言い聞かせたとしても、あなたはおそらく最初にその演習に費やした以上のものを視聴者に求めています。コードに関しては、正直に自問することをお勧めします。もしこれが午前3時に壊れてAIツールがどれも機能しなかった場合、PRのコンテキストと変更を見てデバッグできますか？できないなら、おそらく大きすぎます。大きな文書に関しては、少なくとも、重要なポイントを前もって要約しましたか？誰かが自分でAIに文書を要約させるだけなら、あなたはそれを引き渡す前にその価値を提供するためにもっと努力すべきでしょう。
最後に、AIを使って長ったらしいメールやチャットメッセージを書き、何かを辛抱強く説明しようとしているなら、おそらく実際に会議や電話をする必要があります。ますます長くなるテキストのやり取りは、人々が立ち止まって直接話す必要があるというサインであり、AIの多弁さはそれを変えていません。
AIはあなたの脳や心をオフにする言い訳ではありません。
私たちが脳と心をオフにした兆候には、AI生成作品をレビューしない、人間による編集に時間をかけない、変更を小さな塊に分解しない、AIを介したテキスト交換で実際の会話を避けることが含まれます。このガイダンスはAIの敬意ある使用についてです。なぜなら、同僚に共感し、彼らの時間とスキルを尊重するなら、あなたが誇りに思い、支持し、考え抜いて説明できる仕事を彼らに提供する礼儀を示すからです。AIがアウトプットの多くを生成したかもしれませんが、あなたは完了すべきすべての断片について考え、余分な生産性を利用して何かをより良くしました：より信頼性が高く、よりシンプルで、十分にテストされたものなど。もしあなたがまったく考えずに、盲目的にプロンプトを送り、出力を受け入れ、前進しているなら、それは何かが間違っているという警告サインです。おそらく、Vicki Boykisの開発プロセスに摩擦を加えるアドバイス（または日常業務に相当するもの）を参考にしてください。
これらのガイドラインの枠組み
もしこれを行うことに決めたら、最後のヒント：あなたの会社に何らかの企業価値観があると仮定すると、このようなポリシーやガイドラインを作成する際に、これらの価値観に言及することは常に良いアイデアです。抽象的に「短い方が良い」と言うのは一つのことですが、それを会社の価値観に結びつけることができれば、より強く共鳴するでしょう。例えば、私がアマゾンにいたら、「短い方が良い」をリーダーシップ原則「発明と簡素化」に結びつけることを検討するでしょう。そして、短い方が良いので、これはもう長すぎます。ここで終わりにします。
この投稿を楽しんでいただけましたか？私の著書『マネージャーの道』と『プラットフォームエンジニアリング：テクニカル、プロダクト、ピープルリーダーのためのガイド』もお勧めです。