本記事は、Michael Webster 氏、Kira Muhlbauer、Tim Cheung 氏、Ryan Hamilton 氏からの多大なるご協力のもと執筆されました。
みなさんは、90 年代にインターネットが登場したときのことを覚えていますか。2010 年代のモバイルの台頭はどうでしょうか。どちらも、当初は大げさに騒ぎ立てているだけと思われていました。しかし、迅速でスマートなチームは、これらの登場したての実験段階にある新たなテクノロジーを活用し、ビジネスの変革に成功しました。
そして、今は人工知能 (AI) の時代です。このテクノロジーはもう普及しています。みなさんが AI を試していなくても、競合他社は間違いなく検討を進めているでしょう。
CircleCI では、この 6 か月にわたり、専門のエンジニアチームを組んで業務への AI の活用法を調査してきました。そしてその過程で、この分野に踏み出すうえで役に立つ、段階型の調査方法を編み出しました。この記事では、アプリケーションへの AI の組み込みについて、ブレインストーミングから本番運用まで構想面の指針をご紹介します。最先端の技術を学ぶチュートリアルをご覧になりたい方は、「機械学習に CI を活用する: ビルド、テスト、トレーニング」と「機械学習に CD を活用する: デプロイ、監視、再トレーニング」をご覧ください。また、機械学習 (ML) の詳細については、機械学習モデル開発の課題に関する記事もご覧ください。
さて、AI の活用を迫られていながら、どこから手を付ければよいかわからない状態で、AI を本番運用にまで持ち込むにはどうすればよいのでしょうか。その答えをこれから解説します。
1. ビジネスの目標を特定する
ChatGPT のようなツールを試す場合、まず AI を使って達成したい目標を考えましょう。
CircleCI でビジネスへの AI の活用方法を検討し始めた際には、プロジェクトマネージャー全員を対象として自由回答形式のインタビューを実施し、AI を問題解決に活用するアイデアを尋ねました。
インタビューの質問は以下のとおりです。
- 「現時点で、解決策がない問題はどのようなものがありますか？」
- 「ユーザーから不満が寄せられている問題はどのようなものですか？」
インタビューでは、価値あるアイデアを言いそびれてしまうことがないように、回答者に AI を前提としないで答えを考えるよう明確に依頼しました。CircleCI にとってこのインタビューの効果は非常に大きく、社内の緊急性の高い問題の解決に AI が活かせるとわかり、検討の方向性を定められました。
AI を活用できるビジネス目標の検討に着手する方のために、検討のきっかけを以下にご紹介します。
- 現在抱えている問題をリストアップし、チームまたは自分で「これらの問題は難しくなく、コンピューターに解決をまかせられるとしたらどうなるか」と考えてみる。
- 社内の問題に AI を活用する機会を探す。どのような組織も大量のテキストを抱えており、大規模言語モデル (LLM) はテキストの要約や生成に適しています。未来の名著を生成するとはいかないまでも、AI を活用すればプロらしいメールを書きやすくなるでしょう。
- 現在顧客が手作業で行っている業務を自動化する。たとえば、顧客がテキストを読まなければならない状況なら、LLM の力でテキストの内容を把握しやすくするチャンスです。
ただし、LLM はある種の作業は非常にうまくこなせる一方で、不向きなタスクもあることには注意してください。CircleCI の経験上、LLM が適している作業は次のとおりです。
- 情報を要約する
- 技術的なもの (コード、エラーメッセージ、ログなど) を理解しやすい自然言語に変換する、ある言語を別の言語に翻訳する
- 感情を分析する
- 決まった解法のない作業やクリエイティブな作業
反対に、LLM があまり適さない作業は次のとおりです。
- 自然言語をコードに変換する (人間でないとなおせないミスが生じがち)
- 質問に回答する (GPT が 2021 年以降の出来事を知らないことを思い出してください)
- 正確かつ正しい回答が求められる専門的な作業に対応する (数学の問題など)
この段階から次へ進むにあたって、AI の活用方法を厳密に計画する必要はありません。検討を進める価値がありそうな領域をざっくりとまとめたロードマップを作成すれば十分です。
2. AI を最も活かせそうなチャンスを分析する
次は、インタビューで集めたアイデアを念頭に置いて自社で現在取り組んでいる課題をを評価し、AI テクノロジーを導入する効果がありそうな領域を特定しましょう。
次のように問いかけてみるとよいでしょう。
- 「自社はどのような組織か？」
- 「自社が大切にしているものは何か？」
- 「自社の強みは何か？弱みは何か？」
- 「自社の最優先事項は何か？」
- 「上記の質問の答えに対する AI の活用法として可能性が高いものは何か？」
これらの質問に対する答えを考えると、CircleCI がそうであったように、アイデアが湯水のように湧き出てくることでしょう。しかし、重要なのは優先順位を付けることです。
思いついたアイデアは、複雑さや所要時間、投資額、予想される利益の大きさなどの観点で多岐にわたっていることでしょう。
どのアイデアの見返りが最も大きいか、あるいは最も速く見返りが得られるかを考えてみましょう。
| 投資規模 | 予想利益 | アイデアに対する行動 |
| 小 | 大 | すぐに取り組みを始める |
| 小 | 小 | 利益の大きいアイデアを優先する |
| 大 | 大 | 静観し、未来の優先事項とのバランスを取る |
| 大 | 小 | リストから除外する |
3. チームの AI の専門性を評価し、トレーニングする
アイデアについて、最も実現可能性の高いもの以外も確かめたら、チームの技術面の準備状況を評価しましょう。
評価の際には、技術力、インフラ、データの可用性、ストレージ、処理能力、その他具体的な資産のような要素を考慮するのも理にかなっていますが、問題をより全体的にとらえることをおすすめします。
一般的に言えば、人類が能力や長所、短所、適性、スキル、生まれつきの優位性を身につけるのと同じように、どのような企業でもある程度の技術力、インフラ、実データは自己の裁量で備えているものです。みなさんの組織が秀でている分野は何でしょうか。その長所は、AIプロジェクトにどのように活かせるでしょうか。また、最も有望なアイデアに取り掛かるうえで必要な知識はどのようなものでしょうか。
まずは、ステップ 1 で特定したビジネス目標を念頭に、多数存在する既成モデルのいずれかでそれらの目標を達成できるか検討してみてください。既成モデルで十分なら、普通のソフトウェアエンジニアでもシステムへの組み込みに必要な知識を備えています。機械学習の専門家は必要ありません。
独自モデルの開発、トレーニングが必要であると判断した場合には、該当する機械学習の専門知識を備えた人材を雇用する必要があるかもしれません。
具体的な例として、CircleCI では、AI の力でユーザーのみなさんがコンフィグファイルをより簡単に作成できるよう取り組んでいます。OpenAI などの既存モデルでは、CircleCI のコンフィグファイルを編集しテスト分割のような高度な機能を追加することがうまくできませんでした。その理由は、OpenAI のモデルのトレーニングには主として公開データが用いられているからです。そのため、モデルのトレーニングに使えるコンフィグファイルは、シンプルな構成が多いオープンソースプロジェクトのものに限られており、高度な機能を使った事例はほとんどありません。このような事情で、私たちは多数の CircleCI コンフィグファイルをまとめたコーパスで独自のモデルをトレーニングしなければなりませんでした。
より一般的に言うと、言語モデルにテキストを自動的に要約させたいのであれば、その実現は大して難しくありません。しかし、特定の用途に合わせて出力を調整する場合には、作業量が増えるだけでなく、必要な専門知識やデータも多くなります。
既存モデルを使わずに独自モデルを開発した場合の投資収益率 (ROI) を評価する際には、以下のポイントを参考にしてください。
まず、自社にモデルの調整に対応できるだけのデータがあるか考えてください。目的のユースケースに既存の LLM では対応できないものの、必要なデータもない場合、モデルの調整は基本的に論外です。
次に、使用するデータは品質が高いものでなければなりません。CircleCI Web アプリの例で言うと、使用したデータは、コンパイルに成功するか、人の手によるレビューに合格したコンフィグファイルだけでした。
4. 自由に試し、サンドボックスを用意する
いよいよ、実際に AI を試す段階です。チームに、AI モデルを自由な形で利用できる時間を用意することをおすすめします。成果は考えず、いろいろと試させるのです。こうすることで、このツールの長所や制限にチームを慣れさせることができます。
以下のようなアイデアが考えられます。
- ChatGPT を使い、プロンプトで実験する: 同じ質問を複数回繰り返して、回答が変わりやすいことを実感しましょう。
- モデルに基本的な作業を行わせる (例: 「このコードを修正してください」): モデルの向き不向きをあれこれ考えるのではなく、実際に試して現時点の制約を学びましょう。
- 作業内容をすべて保存する: モデルとの対話の内容は、今後デモアプリケーションやサンプルを使ううえで役に立つかもしれません。製品に活用することはないとしても、Streamlit、Gradio、Hugging Face のSpaces などのツールを使用すれば対話内容を簡単に共有し、低コストでホストできます。
試したモデルに関する以下のような質問にチームが答えられるようになったら、AI を試す段階は終わりです。
- モデルの動作はどのようなものか？
- モデルが適している作業はどのようなものか？
- モデルが適していない作業はどのようなものか？
- モデルの活用法にはどのようなものが考えられるか？
- モデルが抱えるチャンスや危険性にはどのようなものがあるか？
こうして、最先端の AI テクノロジーをいくつか試し、組織にとってどのようなメリットがあるかを検討できたら、サンドボックスの作成に進みましょう。これにより、取引上の機密情報を守り、プライベートデータや独自データが将来的にモデルのトレーニングに利用される事態を防ぎながら、チーム全体で共同して調査を進めることができます。
サンドボックスの作成方法は主に 2 つあります。
- セルフホスト型のオープンソースモデルを使用する: 分離については最適ですが、モデルを自分でホストし、運用しなければなりません。
- トレーニングへの利用を拒否できるサードパーティ製モデルを使用する: CircleCI ではこちらの方法を選びました。OpenAI は、API 使用時にトレーニングへの利用を拒否できます。サードパーティ製モデルの方が自社モデルよりも優れていることが多く、ChatGPT にはこうした問題に対応可能なラッパーが多数用意されています。私たちはフロントエンドとして Chatbot UI を使用しましたが、Hugging UI をはじめとして他にも多数の選択肢があります。
チームでサンドボックス内にて作業を行う場合、以下のポイントに留意されることをおすすめします。
- 楽しむ。
- 好奇心を持ち、質問しあう。
- AI の限界を試す: 限界が判明したら、さらに突き詰めましょう。
- AI が向いている作業と向いていない作業を調べる: 前者には AI を存分に活用し、後者には他のコンピューティングツールを利用しましょう。
- 生成 AI は素晴らしいが、不得意なこともある: 従来の手法の方がはるかに適しているケースもあります。当社エンジニア曰く、「基礎的な計算であれば、LLM に任せるよりも、スプレッドシートや昔懐かしい電卓を使う」そうです。
- 使用するモデルにかかわらず、データポリシー/プライバシーポリシーを熟読する: OpenAI では、共有したデータがトレーニングに使用されることはありませんが、こちらから送信した内容は一定期間にわたり保持されます。
- 知的財産に留意する: LLM の出力は、知的財産の面ではグレーゾーンです。OpenAI は、モデルから出力されたデータに対する著作権は持たないと明言しています。しかし、モデルから著作権の対象となるコードや書籍が出力された場合を想定しておいてください。
- 社内データが他者にアクセス可能になる前に、データに関するポリシーを策定する: LLM に入力してよいものと、絶対に入力してはいけないものを明記しましょう。
CircleCI では、AI を試す段階において、概念実証段階のツールを 2 つ作成しました。エラー要約ツール (CircleCI ユーザー向けに、人間が読んで理解しやすいエラーメッセージを生成するツール) と自己回復型パイプライン (CI のビルドに関する問題を特定し、その修復方法を提案および実装するツール) です
これらの機能は自由な試行錯誤の結果として生まれたものであり、すでにプロダクトロードマップに組み込まれています。顧客やその問題を第一に考えながら実験を行う意思があれば、素晴らしいビジネスへの AI 活用法がきっと見つかるはずです。
5. ツールを選ぶ
ツールを検討する際には、まず次の方針のどれを採用するか決める必要があります。
- サードパーティ製モデルを活用する
- 既存モデルを最適化する
- 独自のモデルを開発する
CircleCI 社内で使用したツールの 1 つとして、データサイエンスと機械学習用のプラットフォームの Hugging Face があります。このプラットフォームには、アプリケーションで使用できるモデル、新モデルのトレーニングに使用できるデータセット、およびアプリケーションのホスト環境である Spaces が用意されています。提供ライブラリを利用すれば、Python によりごく短時間でフロントエンドを構築できます。そのため、社内インフラにデプロイすることなく、社内用プロトタイプをすぐに立ち上げられます。
私たちは、下図のような初期バージョンのエラー要約ツールを Hugging Face 上に構築しました。
現在 CircleCI Web アプリへの組み込みを進めているツールと比べるとかなりシンプルですが、この初期バージョンを通じて実装の検証に必要なフィードバックを集められました。AI 業界には、簡単な社内デモを手間なく作成できるツールが多数揃っており、有望なアイデアのイテレーションを迅速に進められます。
初期におすすめのリソースとツールとしては、以下のものが挙げられます。
- OpenAI API
- OpenAI Cookbook
- LangChain: 言語モデルを搭載したアプリケーションを開発するためのフレームワーク
- Hugging Face Transformer: OSS モデルの利用に適した便利なツール
- Sagemaker: AWS ベースのモデルトレーニングツール。Sagemaker を使用して機械学習開発に CI/CD を組み込むチュートリアルをご覧ください。
ツールを選ぶ際の一番のポイントは、API が適しているかどうか調べるなど、簡単な作業から始めることです。ビルドは、本当に必要になるまで行わないようにしましょう。
最後に、どのツールを選んだ場合でも、CircleCI ユーザーの間で 2 番目に人気の言語へと急成長した Python を学ぶことを強くおすすめします。Python は短時間で身につけられるうえ、ツール選びの幅が大きく広がります (くどいようですが、どのツールを選ぶ場合でも有用です)。ツールは必ずしも必要というわけでなく、ほとんどのツールは代替が効きます。
6.要注意のポイント
実際の運用へと進む前に、AI ツールを利用する際に意識しておくべきポイントをご紹介します。
- スピード
- コスト
- 決定性
- テスト
スピード
AI 推論モデルのスピードには限度があるため、処理速度を落としてパイプラインに AI 呼び出しを実装すべきかよく考える必要があります。たとえば、CircleCI ではこの点を踏まえ、”自己回復型パイプライン” 機能ですべてをチェックするのではなく、エラー発生時のみに実行するようにしています。こうすれば、本当に必要なとき以外は、レイテンシーや API トークンの負担を避けられます。
コスト
AI の実行に欠かせない GPU インスタンスは高コストです。特に、ディープラーニングや機械学習用のアプリケーションには、往々にして莫大なコンピューティングパワーが求められます。こうした用途について、従来の CPU ベースの処理では不十分で、コスト効率も乏しい場合があるため、GPU (グラフィックスプロセッシングユニット) が利用されています。
GPU を利用すれば、膨大な数の計算を同時に処理して、AI ワークロードのスピードを大幅に高められます。しかし、AI モデルのトレーニングには膨大な時間がかかるため、クラウドの GPU インスタンスを利用するとコストがあっという間に膨らみがちです。選んだツールに、リソースの使用状況を確認できる機能と、リソースの消費が大きいビルドは社内インフラで実行できるハイブリッドオプションが用意されているか確認してください。
決定性
私たちソフトウェアエンジニアは、昔から比較的 “純粋な” 関数を利用しており、応答が予測可能であることに慣れています。しかし、AI モデルでイテレーションを行う場合、これまでとは異なり、どの AI/LLM モデルでも応答が変動する可能性があることを受け入れなければなりません。たとえば、計算機は高い正確性、精度、予測可能性を備えているので、5+5 を 100 万回計算させた場合、答えは毎回まったく同じ数値 (10) になります。
しかし、同じように LLM モデルに対して 5+5 の答えを 100 万回質問すると、初めのうちは答えが「10、10.0、十、拾、じゅう、55、10 ドル、10 人」のように安定しないでしょう。これらの答えは、いずれも (“55” も含めて) 特定の状況では妥当 (つまり正しい) とみなせるものですが、応答には大きな変動性があります。LLM は、Temperature パラメーターを小さくした場合でも、1970 年代の電卓や Python の純粋関数に比べると大きな変動性を持つのです。
テスト
AI/LLM をプロダクトに用いると変動性、不確実性が生じるため、これまでとは異なるテストが必要になります。従来のソフトウェア開発では、「入力が X の場合、出力は常に Y」という形のテストを作成するのが当たり前でした。しかし、生成 AI の登場で、テストに対する考え方は変わりました。たとえば、ChatGPT にまったく同じプロンプトを 2 回入力すると、出力は似通ったものにはなっても、まったく同じにはならないでしょう。
つまり、回答が 1 つに限定されないので、おなじみの単体テストを作るわけにはいきません。その代わりに、出力に必ず含まれるべきプロパティを検討し、それをテストする必要があります。
以下のような例が考えられます。
- プロンプトが「この文章を簡潔にしてください」であれば、出力が入力よりも短くなっているかテストします。
- プロンプトが「この文章に絵文字を足してください」であれば、絵文字だけが追加されたかどうかをテストします。
まとめ
本記事の目的は、アイデア出し、調査、テストなど、アプリケーションでの生成 AI の活用について十分に検討するためのフレームワークを提供することでした。CircleCI では、社内 R+D チームの開発現場や、機械学習開発の課題に挑むお客様を通じて、AI/ML に対する関心が急拡大する様子を目の当たりにしてきました。チームでの AI 活用の検討方法を段階的に解説したこのガイドをご覧になったみなさんには、新たに生まれた AI/ML のパラダイムの中でソフトウェア開発そのものがどのように変化するのかを、俯瞰的に考えることをおすすめします。
CircleCI の使命は、ソフトウェアチームがより迅速にイノベーションを実現できるよう、変更を管理することです。従来の CI/CD の観点では、バリデーションの対象となる変更は、人間が行ったものだと考えるのが普通です。開発者が、プルリクエストの形式でコードに変更を加えるのです。今日のほとんどのアプリケーションには、マイクロサービスはもとより、サードパーティサービス、オープンソースライブラリ、パッケージなど、自前のリポジトリ以外のものが多数利用されています。その一方で、生成 AI の登場により、業界が初めて経験する速度でアプリケーションに変化が起きています。
この業界が変化についていくにはどうすればよいのでしょうか。アプリケーションの開発やイテレーションに生成 AI が導入されると、ソフトウェアデリバリーのライフサイクルはどうなるのでしょうか。”ビルド > テスト > デプロイ” という CI/CD の基本的なワークフローが、”ビルド > トレーニング > テスト > パッケージ化 > デプロイ > モニタリング” へと変わるのでしょうか。AI のセキュリティやコンプライアンスはもちろんですが、AI で生成されたコードを運用する際のメンテナンスやサポートは誰が行うのでしょうか。
現時点では、こうした問いに対する答えは、一部を除いてありません。しかし、”イテレーション、測定可能な成果、継続的な信頼関係とコラボレーション” といういつもどおりの方法を守れば、これらの問題を解決できるはずです。
関連情報
