米OpenAIは10月2日（現地時間）、66億ドル（約9670億円）の新規資金を調達したと発表した。資金調達後の評価額は1570億ドル。
この資金により「最先端のAI研究におけるリーダーシップを強化し、コンピューティング能力を高め、人々が困難な問題を解決するのに役立つツールの構築を継続することができる」としている。
米Wall Street Journalによると、Microsoftは10億ドル弱、ソフトバンクは5億ドル、NVIDIAは1億ドル投資したという。
OpenAI、非営利組織から営利企業へとシフトしつつあると報じられている。この動きは投資家を引き付けはしたが、多くの幹部流出につながった可能性が高い。アルトマンCEOの解雇と復帰騒動以来、多数の幹部従業員が退社している。
OpenAIは非公開組織なので収益などは公式に発表していないが、New York Timesによると、2024年の売上高は約37億ドルで、純損失は数十億ドルという。ChatGPTのようなAI技術の構築と運用には電力などに高いコストが掛かる。
New York Timesによると、今回の投資ラウンドの条件には、OpenAIが2年以内に営利企業に転換しなければ資金が負債に転換されることになるという。
⇧ 莫大な資金があっても、なかなか厳しい状況ということなんですかね？
営利企業となってくると、
QCDFとは、品質(Quality)、価格(Cost)、納期や入手性(Delivery)、柔軟性(Flexibility)の頭文字をとったもので、製造業における開発生産業務の評価における指標のひとつである。
QCDSとは、品質(Quality)、価格(Cost)、納期や入手性(Delivery)、対応やサポート(Service)の頭文字をとったもので、製品の評価における指標のひとつである。 関連する概念にQCDFがある。
⇧ このあたりの話が絡んできそうではありますな。
とりあえず、AIの精度を上げて欲しいというのはありますな...
GitHub AppsってGitHub個人用アカウントでも利用できるらしいのとlocalhostで動くらしい
何やら、GitHub Appsは、
⇧ localhostで動くらしいことを、ネットの情報で知る。
とりあえず、
⇧ かなりハマりどころはあるらしい。
GitHub Actionsでしか利用しない場合は、GitHub側に秘密鍵を登録するだけで良いようですが、サーバーとかで稼働しているアプリケーションとやり取りする場合は、サーバーにも秘密鍵を配置しておく必要があると。
サーバーの台数が膨大な場合は、どうすれば良いのか...
GitHub Appsの導入手順を整理しておく
公式のドキュメントによると、
⇧ 手順としては、
- アプリケーション側での作業
- 手順 1: アプリ コードを複製する
- 手順 2: Webhook プロキシ URL を取得する
- GitHub側での作業
- GitHub側/アプリケーション側の両方での作業
- 手順 4: 識別情報と資格情報を格納する
- GitHub側での作業
- 手順 5: アプリをインストールする
- アプリケーション側での作業
- 手順 6: サーバーを起動する
- GitHub側/アプリケーション側の両方での作業
- 手順 7: アプリをテストする
という感じになるってことですかね？
公式のドキュメントによると、
⇧ GitHub Appsを利用できるようにするだけでも、かなり面倒ではある。
公式のドキュメントが分かり辛いんだわ...
GitHub Appsでトークン認証するには、大きく分けてAPIかGitHub Actionsの2択になるっぽい
公式のドキュメントによると、
⇧ GitHub Appにおいて、Git操作のAPIを利用するための認証方法としては、
- アプリとして認証する
- インストールとして認証する
- ユーザーに代わって認証する
の3つの選択肢があるわけなのですが、
アプリのインストールとしての認証
インストールとして認証するために、アプリはインストール アクセス トークンを使用します。 アプリのアクティビティをアプリに属性付けする場合は、アプリのインストールとしてアプリを認証する必要があります。 アプリのインストールとして認証すると、アプリをインストールしたユーザーまたは Organization が所有するリソースにアプリがアクセスできるようになります。 アプリのインストールとしての認証は、ユーザー入力を伴わない自動化ワークフローに最適です。 詳細については、「GitHub App インストールとしての認証」および「GitHub アプリのインストール アクセス トークンの生成」を参照してください。
⇧ ということらしいので、一般的なWebアプリケーションにおいては「アプリのインストールとしての認証」を選択しておけば良さそう。
で、トークンを使用した認証には、トークンの生成処理が必要なわけなのですが、大きく分けて、
の2パターンあるっぽい。
2024年10月4日（金）追記：↓ ここから
何やら、
GitHub には、REST API と GraphQL API という 2 つの API が用意されています。 どちらの API も、GitHub CLI、curl、公式の Octokit ライブラリ、サード パーティ製ライブラリを使って操作できます。 一方の API ではサポートされる機能が、もう一方ではサポートされない場合があります。
⇧「GraphQL API」の存在があり、
という感じになるっぽい。
APIが更に分かれてるのは要注意ってことかしらね...
2024年10月4日（金）追記：↑ ここまで
■RESTによるトークンベース認証（インストールとしての認証）
⇧ という感じになるっぽい。
ただ、
⇧ GitHub Actionsに対してREST APIのエンドポイントが用意されているようで、
repository_dispatch は Github Actions のワークフローをトリガーするイベントの一つです。
これを使うと、外部から Github Actions を実行することができます！
外部からGithub Actionsのワークフローを実行する（repository_dispatch） #GitHub - Qiita
⇧「repository_dispath」というイベントが用意されていて、GitHub Actionsのフローをトリガーするものらしい。
⇧ GitHub Appで「Webhook」を有効にする必要があるってことかね？
どちらにしろ、外部（アプリケーション側ということになるかと）から、何某かのリクエストの処理が必要と。
話が脱線しましたが、GitHub Actionsによる認証トークンの生成については、
今まで非公式なActionに依存していたトークン生成ですが、GitHubが公式でAppsトークンを作成するActionであるactions/create-github-app-tokenを提供するようになったので公式のActionへ依存先を切り替えられるようになりました。 実際、GitHubのドキュメントでは今までtibdex/github-app-tokenを使う手順が紹介されていましたが、actions/create-github-app-tokenを使うように変更*2されています。
⇧ 長らく、公式で用意されてこなかったらしい...
どちらにしろ秘密鍵はアプリケーション側で参照できる必要がある
公式のドキュメントによると、
Wikipediaによる「JWT（JSON Web Token）」の説明を見ると、
概要
JWTでは、トークン内に任意の情報（クレーム）を保持することが可能であり、例えばサーバはクライアントに対して「管理者としてログイン済」という情報を含んだトークンを生成することができる。クライアントはそのトークンを、自身が管理者としてログイン済であることの証明に使用することができる。トークンは当事者の一方（通常はサーバ）または両方（もう一方は公開鍵を提供する）の秘密鍵により署名されており、発行されたトークンが正規のものか確認することができる。
⇧ となっており、「秘密鍵」が必須のようです。
で、アプリケーションのあるサーバーからGit操作のAPIを利用するには、
- アプリケーションでGit操作のAPIを利用するための認証が必要
- 認証のためには認証トークン(※1)を取得するリクエストが必要
- 認証トークン(※1)を発行するリクエストには、JWT（JSON Web Token）が必要
- JWT（JSON Web Token）の生成には秘密鍵の情報を含ませることが必要
- アプリケーションの稼働しているサーバーから秘密鍵の情報にアクセス出来る必要がある
※1 「インストールとして認証する」の場合は「インストールアクセストークン」となる。
という感じなのですな。
ここで、サーバーが1000台あったとしよう。
これ、1台1台に対して、異なる秘密鍵を配置するとなると、GitHub App側に公開鍵を登録する作業も発生するからして、想像するだけで血の気が引いてきますな...
本来であれば、漏洩リスクを考慮して、1台1台に個別の秘密鍵を割り当てるのがセオリーなのかもしれませんが、クラウドサービスプロバイダー側が提供しているサービスを信用して、
⇧ 上記サイト様にありますように、「Azure Key Vault」のようなサービスで誤魔化すという手段ぐらいしか思いつかんのよね...
一応、GitHubの公式のドキュメントでも、
⇧「Azure Key Vault」などのサービスを検討って話は出てますな。
台数は少ないケースの質問なのだが、
The more places where your private key is stored, the higher the risk of a compromise. The fewer keys you use, the more impact a compromised key may have.
https://serverfault.com/questions/973654/using-ssh-keys-with-multiple-computers
⇧ というような回答があるからして、1000台のサーバー全てに個別の秘密鍵を配置するというのは、避けて良さそうということかね？
サーバーが配置されてる場所が別々だから、「Azure Key Vault」などのサービスから秘密鍵の情報を参照できるようにする以外が思い付かんよね...
まぁ、通信経路もセキュリティが為されていると信じて、管理を集約させたいっすな、人間だもの。
とりあえず、GitHubのGitHu Appsの公式のドキュメント、
- GitHub側の作業
- アプリケーション側の作業
の区別を明確にしておいて欲しい...
あと、GitHub Appで必要な情報も分かり辛いのよ...
毎度モヤモヤ感が半端ない…
今回はこのへんで。
