話題中のmanus.imを使ってChatgpt Enterpriseに対して検討してもらったので結果共有します。
元々の質問
chatgpt enterpriseの機能を知りたいです。特に3万人の企業で使う予定ですので、セキュリティ、ガバナンス、作業効率などの観点でどのくらいメリットがあるのか知りたい。
ここにいろんなマニュアルがあります
https://help.openai.com/en/collections/5688074-chatgpt-enterprise
15分後1回目の調査結果を頂きました。
SSO, SCIM, and User Management SSO Overview
SSO は、エンタープライズおよび教育機関向けの顧客のみが利用可能です。
背景のアーキテクチャと用語
現在、ChatGPT および API プラットフォームの両方で、SAML 認証を通じた SSO がサポートされています。
•ワークスペース：ChatGPT のインスタンスを指します。
•組織（Organization）：API プラットフォームのインスタンスを指します。
•アイデンティティプロバイダー（IdP）：デジタル ID を管理するために使用するサービスを指します。当社は、SAML をサポートするすべての IdP との接続をサポートしています。代表的な IdP には以下が含まれます：Okta,Azure Active Directory/Entra ID, Google Workspace
現在、各 ChatGPT ワークスペースには、それに対応するプラットフォーム組織が関連付けられています。
つまり、エンタープライズ プラットフォームの「一般」ページにある 組織 ID（org-id） は、エンタープライズ ChatGPT ワークスペースに関連付けられている 組織 ID（org-id） と同じです。
そのため、ワークスペースと組織は同じ認証レイヤーを共有しています。
公式ドキュメントの更新時間は2024年6月のままですので、あまり機能更新していないかもしれません。
ChatGPT Enterpriseとは？
ChatGPT Enterpriseは、企業向けのセキュリティとプライバシーを備えたサブスクリプションプランです。無制限の高速GPT-4oアクセス、長い入力を処理できる拡張コンテキストウィンドウ、高度なデータ分析機能、カスタマイズオプションなど、さまざまな機能を提供します。
自社でChatGPT Enterpriseを利用するには？
ChatGPT Enterpriseを導入したい場合は、営業チームにお問い合わせください。「どの製品やサービスに興味がありますか？」の項目で「ChatGPT Enterprise」を選択してください。
ChatGPT Enterpriseのセキュリティとプライバシー管理について
ChatGPT Enterpriseでは、ビジネスデータをユーザー自身が所有・管理できます。お客様のビジネスデータや会話を学習に使用することはなく、モデルも使用履歴から学習しません。また、ChatGPT EnterpriseはSOC2準拠であり、すべての会話は送信時および保存時に暗号化されます。
さらに、新しい管理コンソールでは、チームメンバーの管理、ドメイン認証、SSO（シングルサインオン）、利用状況のインサイト機能を提供し、エンタープライズ環境での大規模導入を可能にします。
詳しくは、プライバシーページやTrust Portalをご覧ください。追加のご質問がある場合は、営業チームまでお問い合わせください。
ChatGPT Enterpriseのその他の特徴
ChatGPT Enterpriseでは、以下の点が一般ユーザー向けプランと異なります：
• 無制限のGPT-4 Turboアクセス（使用制限なし）
• 高速なパフォーマンス
• 高度なデータ分析機能の無制限利用（旧Code Interpreter）
• 共有可能なチャットテンプレート（企業内のワークフロー構築や共同作業に活用可能）
ChatGPT Enterpriseのサポートを受けるには？
問題が発生した場合は、ヘルプセンターのチャットツールを使ってサポートチームにお問い合わせください。迅速に対応いたします！
DPEが最近流行っているようで、関連資料をメモしてみました。
DPE(Developer Productivity Engineering)が新しいソフトウェア開発工学の方法論で、ビルド・テストとCIなどの自動化ツールにフォーカスしています。その実践をDPEチームにより担当されます。
DPEとSREの違いは、SDLCフェーズの違いであって、DEV(development & test)開発生産性とOPS(deployment & maintenance)運用信頼性の違いだと思われます。
なお、DXE(Developer Experience Engineer)はDPEを実現するためのエンジニアロールの一つと自分が解釈しています。
ちなみに、GoogleのEngineering Productivity部門にDPEやDXEとのロールがなく、通常のSoftware Engineer (SWE)とTest Engineer (TE)だけあります。
4年前に開発生産性を考えるサービス化(API化)の本質はソフトウェア開発産業化記事は、DPEのようにツールチェーンのことを意識していたが、明確的に言葉定義として出てこなかったのが残念。
1 From QA to Engineering Productivity
Google Testing Blog Tuesday, March 22, 2016
In summary, the work done by the SETs naturally progressed from supporting only product testing efforts to include supporting product development efforts as well. Their role now encompassed a much broader Engineering Productivity agenda.
2 The Effect of Work Environments on Productivity and Satisfaction of Software Engineers
Brittany Johnson, Thomas Zimmermann, Senior Member, IEEE, and Christian Bird, Member, IEEE
2019/09
3 Developer Productivity Engineering: Introduction and Key Concepts
gradle.com By Dennis Welter
September 9, 2019
Hans Dockter, CEO & Founder of Gradle, talks about the emerging practice of developer productivity engineering, a discipline of using data to improve essential development processes from build/test to CI/CD.Topics covered in this webinar are:
Quantify the costs of a low productivity environment with wasted time waiting for builds, tests, and CI/CD pipelines
Communicate the importance of fast feedback cycles and catching errors earlier, including incorrect signals like flaky tests
Discuss acceleration technologies for speeding up feedback cycles
Make the practice of developer productivity engineering a respected discipline
Use data to understand and improve essential development processesビルド、テスト、CI/CDパイプラインの待ち時間にかかる無駄な時間など、生産性の低い環境におけるコストを定量化する
フィードバックサイクルを高速化し、不具合テストのような不正確なシグナルを含むエラーを早期に発見することの重要性を伝える。
フィードバックサイクルを高速化するためのアクセラレーション技術について説明します。
開発者生産性エンジニアリングの実践を尊重される規律とする
本質的な開発プロセスを理解し、改善するためにデータを使用する
https://trailhead.salesforce.com/
https://trailblazer.me/id/yinlei
分かりやすいので紹介しておきます。
ITmediaの記事
「モノのサービス化」の前提として、「モノのSD化」があります。SD（Software Defined）とは、「ソフトウェアで定義された」あるいは「ソフトウェアで規定する」という意味です。「モノのSD化」によって、モノづくりは、「性能や機能の優れたモノをつくること」を目指すことから、「常に最適なモノを使い続けてもらうこと」を目指すことへ変わりはじめています。つくった後のことまで考え、それを支えていくモノづくりが求められます。つまり「モノのサービス化」というパラダイムシフトが、起ころうとしているのです。
「モノを使うこと」の最適化を実現するには、モノの状況をデータとして捉える仕組みが必要となります。これがIoTです。
モノに組み込まれたセンサーが、モノのさまざまな状況をデータ化し、ネットワークを介してメーカーに送ります。メーカーは、それを解析して状況を把握し、モノに組み込まれたソフトウェアを改修したり更新したりすることで、機能や性能、操作性を改善します。
また、集められたデータは、より優れた製品を開発するための情報としても用いられます。ハードウェアは、そんなソフトウェアとの関係を前提に機能や性能をつくっていかなければならないのです。
全日本空輸（ANA/NH）は、3月22日午前8時20分ごろ発生した国内線予約システム「エイブル」の障害について、午後8時10分ごろ復旧したことを明らかにした。この影響で、22日はANAの国内線だけで146便が欠航し、約1万8200人に影響が出た。遅延便も391便にのぼり、約5万3700人に影響が及んだ。
ANAによると、システムを構成する4台のサーバーのうち、22日午前3時44分に1台が停止。その後午前8時15分には新たに2台が停止し、午前8時22分には残る1台も停止した。この時に、サーバーの保守作業などは行われていなかったという。
その後1台を再起動し、2台目の再起動作業に取りかかったところ、正常に動作しなかった。このため、再起動に成功した1台のみ稼働させ、空港で搭乗手続きなどに使う「空港系システム」を午前11時30分ごろ復旧させた。
同社ではバックアップ用システムも用意していたが、切り替えに1時間程度掛かることから、朝の混雑時間帯の混乱を避けるため、再起動した1台を中心に復旧作業を進めた。ウェブサイト上での国内線予約や決済、座席指定、チェックインなどに使う「予約販売系システム」は、午後8時10分ごろ復旧した。
ANAでは、4台のサーバー間で顧客データベースを同期させるシステムに障害が発生したとみて、原因究明を急いでいる。現時点では、ハードウェアとソフトウェアのどちらに問題があったかなど、特定に至っていない。
現在の国内線予約システムは、2013年7月に稼働。今回の障害発生まで、システムが停止するトラブルは起きていないという。通常期の予約販売は1台のサーバーで対応できるが、繁忙期は2台分の処理能力が必要だとして、その2倍にあたる4台でシステムを構築した。