4Aモデル(AI Agent Application Architecture)は、LLMベースのAIエージェントアプリケーションを迅速かつ拡張性高く構築するためのリファレンスアーキテクチャです。以下の6つのレイヤーで構成され、エンタープライズ用途に対応可能なセキュリティ・柔軟性・観測性を備えています:

User Interface Layer
Gateway Layer
Orchestrator / Reasoning Layer
MCP Server / Tool Layer
Data / API Layer
Context / Memory Layer
What is ChatGPT Enterprise?
公式ドキュメントの更新時間は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のサポートを受けるには?
問題が発生した場合は、ヘルプセンターのチャットツールを使ってサポートチームにお問い合わせください。迅速に対応いたします!
コード×AIーソフトウェア開発者のための生成AI実践入門を読んだ感想や今まの業務の中の自分の学びのまとめです。
全体感想
開発組織レベルでAIの最大限活用のため、個人のスキルセットだけではなく、組織全体で生成AIの力を引き出す方法が必要
AIと協調しながら個人が成長し、それから組織の成長に繋がる好循環を生み出す
3つのステップ
1、既存の個人やチームのナレッジを共有して、AIが活用可能な形式に変換する
2、組織のナレッジを透明化し、多くの人がアクセス可能にする
3、共用ナレッジ資産を常に最新状態に維持していく
開発組織として考えられるナレッジ資産
高品質なソフトウェアライブラリ
PJの設計書や運用ドキュメント
再利用可能なソースコードの断片(ロジックやアルゴリズムなど)
開発規約やガイドライン
共通PFのマニュアル及びサンプルコード
設計手法や運用ノウハウ
AI生成時における中間成果物やドキュメント
AIと協働するための技術スタックの内部標準化
日本航空JL474便 / 高松発 - 東京(羽田)着
2023/08/13 8:30 AM RWY34 Landing





2023/08/13 8:33 AM Spot9


数年前に似た障害があったが、
ANAシステム障害 顧客DB同期処理失敗?
ANAシステム障害 顧客DB同期処理失敗? その2
今回は別の原因がらしい。
4月3日に発生した国内線システム不具合の原因及び再発防止策について
4月3日に発生したシステム不具合により、多数の国内線に欠航・遅延を生じさせる結果となりました。ご利用のお客様、関係の皆様に多大なご迷惑をお掛けいたしましたこと、深くお詫び申し上げます。
この度の不具合につきまして調査を行った結果、原因が明らかになりましたので、再発防止策とあわせてご報告申し上げます。
発生原因
国内線旅客システムのデータベースにおける、ソフトウェア不具合であることが判明しました。具体的には、予約管理業務のために、特定のデータを抽出する日常の処理において、ソフトウェアのバグを起因とするエラーが発生し、データベースサーバー2台が一時的に高負荷状態となりました。その結果、データ処理が滞り、サーバー2台が同時停止しました。
再発防止に向けた対応
(1)データ抽出方法の変更
(2)データベースサーバーが2台同時に停止しないための制御プログラムの強化
上記を確実に実施した上で、万が一、今後システム障害が発生した場合に備え、バックアップシステムへの迅速な切りかえ、訓練の実施などの対策を講じるべく、引き続き対応を図ってまいります。
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のようにツールチェーンのことを意識していたが、明確的に言葉定義として出てこなかったのが残念。
DPE - Developer Productivity Engineering
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パイプラインの待ち時間にかかる無駄な時間など、生産性の低い環境におけるコストを定量化する
フィードバックサイクルを高速化し、不具合テストのような不正確なシグナルを含むエラーを早期に発見することの重要性を伝える。
フィードバックサイクルを高速化するためのアクセラレーション技術について説明します。
開発者生産性エンジニアリングの実践を尊重される規律とする
本質的な開発プロセスを理解し、改善するためにデータを使用する
SailPointのアイデンティティ・プラットフォームとIdentityNowの違い
IdentityNow
1 SaaS-based identity governance platform
2 機能:
a プロビジョニング provisioning
b アクセス権申請・付与 access requests
c パスワード管理 password management
d アクセス権の棚卸 access certification
e 職務分掌/ポリシー管理 separation-of-duties
SailPoint Identity Platform
1 incorporates AI and machine learning into the core IdentityNow platform
2 機能
a アクセス権インサイト Access Insights
b アクセスのロール権限定義 Access Modeling
c レコメンデーションエンジン Recommendation Engine
d マルチクラウドアクセス管理 Cloud Governance
0、用語集
entitlement 権限、例:特定入室権限、ファイルアクセス権限、フォルダーアクセス権限
access profile アクセス権限集(複数権限の集合、例Admin, Guest)
role 役割・ロール
certification 棚卸
source 3rdパーティーのアプリケーションやDBなどのユーザー
1、プロビジョニング
プロビジョニングとは
プロビジョニングとは、必要なシステムやアプリケーションに対し、ユーザーアカウントの作成、変更、削除を行うことです。高度なプロビジョニングソリューションの場合、ユーザー属性のみにとどまらずアクセス権限も含めて管理し、アカウントを利用用途や業務上の役割に応じて運用し、IT部門の負荷軽減や管理業務の自動化に寄与します。
概要:
アプリケーションへの適切なアクセス権を自動で設定
機能:
a プロビジョニングの⾃動化
IT部門のプロビジョニング作業は、各種アプリケーションに対する権限をロール(役割)ごとに付与する設定を事前にしておくことで、SailPoint IdentityNowが採用や退職等の人事情報の変更を検知し、役割に応じた権限を自動でプロビジョニングします。
b 権限の⾃動更新
権限の⾃動更新は、ユーザーの⼈事異動や役職変更などの⼈事イベントが発⽣した際、SailPoint IdentityNowで⾃動的に各アプリケーションに適切な権限変更を⾏う機能です。
企業では退職したユーザーのIDが各アプリケーションにログイン可能な状態で放置されていることも少なくありません。
Scaling Kubernetes to Over 4k Nodes and 200k Pods
PayPalはApache MesosからKubernetesへ移行しようとしていて、ただパフォーマンスチューニングでは大変苦労したことを記事にしてくれました。
Apache Mesosでは簡単に1万Nodeまでスケールアウトしましたが、Kubernetesでなかなか負荷テストが通らなかったそうです。色々やった結果は4000止まり。
ちなみに負荷テストツールはk-benchを利用していました。
テスト環境:
ーGCP
ーWorker Nodeスペック:4CPU、最大40Pod
ー規模:3つMaster Node、3つNodeのetcdクラスター、4100 Worker Node、20万Pod
服务网格数据面性能深度调优
1 default状態

あるFlame Graph調査では、sidecar のenvoyの CPU利用率の半分はKernel TCP/IP stackになります。
2 Pod内通信について、赤の1の部分をTCP/IP stackをSockopsに変換し、サービスとsidecar間のレイテンシは、10%低減。

データベースシャーディングアーキテクチャの新たな進化
DBシャーディング技術は自分としては20年以上前から使ってきたもので、枯れた技術の一つだが、トランスペアレントシャーディング(transparent sharding)について大変興味あります。
何故かというと、一旦shardingが決まったら、拡張のためのデータの移行が非常に難しく、実現性のある簡単な方法がないことです。
/filters:no_upscale()/articles/next-evolution-of-database-sharding-architecture/ja/resources/33-1642067502898.jpeg)