新着 の記事一覧

こんにちは、GMOインターネットグループ株式会社 フロントエンドエンジニアの浦田です。ConoHaは現在、大進化の時期に差し掛かっており、チーム一同大奮闘中でございます。そんな中で今回は、ConoHaコンパネのシステム設計やGUIアーキテクチャパターンについて入社一年目で学んだ内容を共有したいと思います。 はじめに ConoHaコントロールパネルでは、ドメイン駆動設計を使用し、「保守性」「再利用性」「拡張性」が高くい変化に強いソフトウェアの設計を心がけております。 本記事では、ドメイン駆動設計をベースに、GUIアーキテクチャなどフロントエンドにおけるソフトウェアの設計についてメリット・デメリットとともに解説したいと思います。 ドメイン駆動設計 システムにおけるドメイン駆動設計について少し解説したいと思います。ビジネスドメイン（業務領域）を中心に据え、ビジネスルールやプロセスをソフトウェア設計に反映させます。これにより、開発者はビジネス要件に集中し、ドメインの理解を深めながら柔軟かつ効果的なソリューションを構築を行うことができます。問題領域の複雑さに対処し、ソフトウェアの保守性、再利用性、拡張性を備えた変化に強いソフトウェア設計です。 コンパネ開発においてドメイン駆動設計のメリットデメリットを現場の声とともにまとめてみました。 メリット 書くところ（クラス）が決まっているので簡単要件を正確に反映させたモデルを作成できる保守性と可読性の向上 デメリット 複雑性の増加・実装量が多い学習コストが高い ユビキタス言語の意識から可読性が高く、要件が分かりやすいクラスは、実装者と事業者とのやり取りをよりスムーズなものにできていると感じています。 MVP ConoHaではGUIアーキテクチャーパターンを使用して、フロントエンドの設計を行っています。パターンには様々あり、原点となるMVCパターンは、ユーザの入力をControllerが受け取り、ControllerがModelを操作し、その結果をViewでユーザーに返します。ConoHaではControllerがViewに組み込まれ、PresenterがModelとViewの制御を行うMVPパターンを採用しており、踏襲した形で一部にアレンジを加えています。フロントの設計方針（クラスの定義）についてはこちらに記載してありますのでご覧ください。以下ではフロントにおける「保守性」「再利用性」「拡張性」についてまとめてみました。 保守性： View: 画面描画や情報取得を集約し、変更があってもViewのみに影響を与えるため、保守性が高まります。Presenter: EventHandlerとの連携で、必要な変更点が限定され、変更時の修正範囲が明確です。Repository: インターフェース経由で参照するため、バックエンドの変更があっても影響が局所的で、保守作業が容易です。 再利用性： Selector：セレクタや属性の定義を一元管理し、再利用と保守が容易です。変更が必要な場合、Selectorのみを修正すれば済みます。Repository：インターフェースによって異なるバックエンド実装を切り替えやすく、コードの再利用性を高めます。 拡張性： EventHandler：新しいイベントの追加や既存イベントの変更が可能で、システムの拡張が柔軟です。バックエンド通信の追加もPresenterを介して容易に行えます。 この設計において、各要素の役割分担が明確であり、変更に対する影響範囲が限定的なため、保守性が高まり、再利用性と拡張性も確保されています。以上の設計を実際に実装して感じた、メリットとデメリットをまとめてみました。 メリット 実装者間のバラつきが少なくなった可読性の向上モジュールが独立しているため、修正が他の部分に影響を与えにくく保守性が向上する デメリット 実装量が多い学習コストが高いことファイル数が増えたのでコンパイルに時間がかかるようになった気がする... おわりに いかがだったでしょうか。 以上が、ConoHaコントロールパネルのフロント設計になります。皆様により長くConoHaをご愛顧いただけるよう、私自身、まだまだ駆け出しのフロントエンドエンジニアではありますが、日々奮闘していきたいと思います。

初めまして！GMOインターネットグループ株式会社、新卒2年目の江﨑です。今回は初心者が一から負荷テストについて学び、実施した経験についてお話しします。 はじめに 今回、オンプレミスのサービスのクラウドリフトに伴って負荷テストを行う必要がありました。私は普段、フロントエンドエンジニアとしてサービスのUI改善を行っており、負荷テストは未開の領域でした。そのため、一から負荷テストについて学び、多くの知見を得ることができたのでこれから学ぶ方の参考になればと思い、執筆させていただきました。 使用ツール Distributed Load Testing on AWSApache JMeter 今回はAWSが提供する Distributed Load Testing on AWS を用いて実行環境を簡単に構築し、細かいシナリオは Apache JMeter で作成しました。 ■Distributed Load Testing on AWSDistributed Load Testing on AWS ソリューションは、大規模および負荷時のソフトウェアアプリケーションテストを自動化して、リリース前に性能上の潜在的なパフォーマンスの問題を特定するのに役立ちます。このソリューションは、一定のペースでトランザクションレコードを生成する数多くの接続ユーザーを作成およびシミュレートします。サーバーをプロビジョニングする必要はありません。また、このソリューションでは、複数の AWS リージョンにまたがってテストを実行することができます。詳細：https://aws.amazon.com/jp/solutions/implementations/distributed-load-testing-on-aws/ 公式では上記のように紹介されています。 Distributed Load Testing on AWS 構成図 サーバーレスな負荷生成コントローラー・エンジン & Web UI を提供しています。（コントローラーは Taurus を使用）既存サービス（負荷テスト先）のクラウドリフトで忙しい中、負荷テスト元の実行環境を一から構築するとなると途方に暮れてしまいます。そんな手間を省いてくれる便利なツールとなっています。下記公式ガイドから簡単に環境構築できる AWS Cloud Formation を立ち上げることができます。実装方法の詳細については公式ガイドをご覧ください。https://d1.awsstatic.com/Solutions/ja_JP/distributed-load-testing-on-aws.pdf ■Apache JMeterApache JMeter™ アプリケーションはオープンソースソフトウェアであり、機能動作の負荷テストとパフォーマンスの測定を行うために設計された100%純粋なJavaアプリケーションです。元々はWebアプリケーションのテスト用に設計されましたが、その後他のテスト機能にも拡張されました。詳細：https://jmeter.apache.org/ 公式では上記のように紹介されています。GUIで直感的に操作ができ、プラグインを用いて様々なシナリオを作成できます。メジャーなツールであるため、ネット上に多くの記事が公開されています。また、日本語にも対応しているため英語が苦手な私でも難なく利用することができました。 シナリオ作成 シナリオは負荷テスト先のアプリケーションによって異なるので、今回は使われる機会が多いと思われる機能を抜粋して紹介します。 Thread Group Thread Group ・スレッド数や Ramp-up 期間、ループ回数を設定する機能・今回は Distributed Load Testing on AWS で設定するため全て 1 に設定 HTTP Cookie Manager HTTP Cookie Manager ・Cookie を使用する場合に必要となる機能・自動取得された Cookie はスレッドごとに管理される HTTP Request HTTP Request ・GET や POST などアプリケーション内で想定するユーザーのリクエスト内容を設定・ユーザーが行う一連の流れを作成することで解像度の高いシナリオを作成できる Regular Expression Extractor Regular Expression Extractor ・HTTP Request で取得した Body や Response Header から値を正規表現抽出する・上の画像では input 要素から value 属性の値を抽出して TOKEN 変数に代入している 他にも様々な機能があるので負荷テスト先のアプリケーションに合ったシナリオを作成してみてください。 負荷テスト実施 Distributed Load Testing on AWS に作成したシナリオをアップロードして負荷テストを行っていきます。 Create Load Test Task Count・負荷エンジンとなる Fargate タスク数Concurrency・タスク毎に生成される仮想ユーザー数・Task Count × Concurrency = 同時接続数Ramp Up・Concurrency に達するまでの時間（0 以上, 単位：秒 or 分）・Ramp Up 時間を増やすと徐々に負荷がかかるHold For・Concurrency を維持し続ける時間（1 以上, 単位：秒 or 分）・Ramp Up 10分 + Hold For 50分 = 負荷テスト 1時間 上記項目入力後、Apache JMeter で作成したシナリオをアップロードして実行するだけで負荷テストが行われます。 負荷テスト結果 Test Results Avg Responce Time・すべてのリクエストの平均応答時間（秒）Avg Latency・すべてのリクエストの平均レイテンシ（秒）Avg Connection Time・すべてのリクエストについて、ホストへの接続にかかった平均時間 （秒）Avg Bandwidth・すべてのリクエストの平均帯域幅Total Count・リクエスト総数Success Count・成功したリクエスト総数Error Count・エラー総数Requests Per Second・すべてのリクエストの 1 秒あたりの平均リクエスト数Percentile Responce Time・テストの応答時間のパーセンタイル値（最大応答時間は 100%、最小応答時間は 0%） Error が発生していたり、Responce Time が異常に遅い場合は負荷テスト先のアプリケーションでボトルネックが発生しているため解消する必要があります。今回は Amazon CloudWatch や AWS X-Ray でボトルネックを確認し、クラウド環境の構成を見直し、修正しました。その後再負荷テストを行い、問題が無いことを確認してからアプリケーションのリリースを行いました。 おわりに 今回の経験を通して、負荷テストはお客様に安定したサービスを提供するための指標となることを学びました。正常に稼働しているシステムでも、負荷の大きいリクエストを送られたり、長時間稼働し続けるとエラーを出してしまいます。そういった不測の事態を避けたり、システムの限界を把握しておくためにも、リリース前の負荷テストは重要です。今回ご紹介したように、面倒な環境構築を行わずとも負荷テストを実施できる便利なツールが世の中には存在しますので、皆さまも是非、自身のサービスに対して負荷テストを行ってみてはいかがでしょうか。

GMOインターネットグループは、学生エンジニア向けオンライン勉強会「技育CAMP アカデミア」にて、GMOエキスパートシリーズを開催します！今回はデベロッパーエキスパートの津田 良太郎が登壇し、「Web3Dグラフィックス表現でライバルに差をつけろ！」について勉強会を実施いたします。学生のみなさん是非ご参加ください！ 技育CAMPとは？ 「自ら考え、自ら創る」ことができる未来のエンジニアを育てるキャリア育成プログラム「技育プロジェクト」の一環で、「未来の技術者を育てる」ことを目的とした、エンジニアを志す学生の皆さんにハッカソンと勉強会を通して継続的なインプットとアウトプットの場を提供するスキルアップ支援プラットフォームです。 GMOインターネットグループはその理念に共感し、スポンサーとして年間協賛しています。 イベント概要 開催日時：2023年10月19日（木）18:00～19:00会　　場：Zoomにてオンライン開催参加費用：無料（事前登録制）公式HP：https://talent.supporterz.jp/events/ade413f8-e3e4-4593-8ec3-dc15a16c6713/主　　催：株式会社サポーターズ 参加申し込みはこちら 「Web3Dグラフィックス表現でライバルに差をつけろ！」 GMOインターネットグループ デベロッパーエキスパート津田 良太郎（@utautattaro） Webフロントエンドフレームワークやデザインフレームワークなどの登場で、誰でも簡単にWebシステムが構築できるノウハウが溜まってきました。本公演ではあえてそこでは触れられることの少ないWeb3Dグラフィックスに焦点を当てて、一段上のWeb表現を実装する方法を学びます。開発内容はApple Vision Proでの開発にも対応。四角い画面からも飛び出すような表現力を手に入れてフロントエンドエンジニアリングを楽しみましょう。 ＜注意事項＞申し込み人数が予定数に達した場合、申し込み締切日より前に受付終了いたします。アーカイブは残しませんので、当日是非ご参加ください！ こんな方におすすめ Webフロントエンド技術や、UI/UXなどユーザーに見える部分の開発に興味がある方。ゲーム開発経験があり、Web技術にも興味がある方。 最後に 学生の皆さまのご参加をお待ちしております！ 参加申し込みはこちら

GMOインターネットグループは、学生エンジニア向けオンライン勉強会「技育CAMP アカデミア」にて、GMOエキスパートシリーズを開催します！今回はデベロッパーエキスパートの駒井 直が登壇し、「あなたのプログラミングを仕事のコードにするためのTips集」について勉強会を実施いたします。学生のみなさん是非ご参加ください！ 技育CAMPとは？ 「自ら考え、自ら創る」ことができる未来のエンジニアを育てるキャリア育成プログラム「技育プロジェクト」の一環で、「未来の技術者を育てる」ことを目的とした、エンジニアを志す学生の皆さんにハッカソンと勉強会を通して継続的なインプットとアウトプットの場を提供するスキルアップ支援プラットフォームです。 GMOインターネットグループはその理念に共感し、スポンサーとして年間協賛しています。 イベント概要 開催日時：2023年10月17日（火）18：30～19：30会　　場：Zoomにてオンライン開催参加費用：無料（事前登録制）公式HP：https://talent.supporterz.jp/events/0970398c-71aa-4b0b-ab87-3dbacbd30728/主　　催：株式会社サポーターズ 参加申し込みはこちら 「あなたのプログラミングを仕事のコードにするためのTips集」 GMOインターネットグループ デベロッパーエキスパート駒井 直 セキュリティ、コンプライアンス、運用性能といった、皆様のプログラミングを仕事にするための要素を俯瞰的に解説します。本プログラムに興味を持ちご参加いただいている皆さんは、テクノロジーやプログラミングに触れ、"作って、動いた、面白い"に感動した方々と思います。そんな感動を仕事にしてみたい、事業として世の中に送り出したいと考えるかもしれません。その時には、皆様が日常取り組んでいるであろうプログラミングの中に、プロの事業で使ってもらう視点を埋め込んでいく必要があります。それは、自分の作ったものを他の人が運用する為に必要なログの出し方だったり、データを自分が勝手に触れないようにする仕掛けだったり、システムがトラブった時に影響を極小化する仕組だったりします。Webサービスを例にして、仕事で使えるプログラムって何？という事をざっくり解説します。 ＜注意事項＞申し込み人数が予定数に達した場合、申し込み締切日より前に受付終了いたします。アーカイブは残しませんので、当日是非ご参加ください！ こんな方におすすめ 自分である程度動くプログラミングを書いてみて、仕事にしてみたいな、と思う方職業エンジニアになると決めて学習しているけど、いざ仕事になると何か違うのかな？と不安に思う方※特定の言語やプラットフォームの解説はしません 最後に 学生の皆さまのご参加をお待ちしております！ 参加申し込みはこちら

9月26日（火）にオンラインで開催された「GMO Developers Night #38」では、オンライン総合決済サービスを展開するGMOペイメントゲートウェイ株式会社が登壇。決済代行業界初のサポートセンター国際認定を取得したカスタマーサポートの裏側について紹介しました。イベント告知：https://developers.gmo.jp/37658/ 登壇者 GMOペイメントゲートウェイ株式会社 システム本部 カスタマーサポート 部長　田中 弘道テクニカルサポートグループ　佐山 量哉サポート企画グループ　土屋 優希コンタクトグループ 課長　寺村 杏里 笑顔の絶えないハイクオリティなサポートセンター 冒頭では、田中がGMOペイメントゲートウェイ株式会社（以下、GMO-PG）およびカスタマーサポートの概要や特徴について説明しました。 GMO-PGは、オンライン事業者・公的機関等の加盟店に対し総合的な決済関連サービスを提供しており、社名のとおり加盟店と決済をつなぐゲートウェイの役割を果たしている会社です。2023年6月末現在においては、連結加盟店舗数15万5598店、年間連結決済処理件数58.6億件、年間連結決済処理金額14兆円という実績で、毎年営業利益25%成長を目標に増収・増益を続けています。 こうした会社の成長を支えるGMO-PGのサポートセンターは、システム本部の配下に所属しており、コンタクトグループ（G）、テクニカルサポートG、プロセシングサポートG、サポート企画Gの4つのグループから構成されています。 田中によると、GMO-PGのサポートセンターの特徴は大きく分けて5つあるといいます。 1つめは、エンジニア出身者が複数在籍している点。2つめは、ハイレベルな接客業界出身者が多数在籍している点。このような背景もあり、HDI格付けベンチマーク「クオリティ格付け」において、最高評価となる三つ星を6年連続で獲得。また、2023年6月にはセンター認証の最高峰である「HDIサポートセンター国際認定」が決済代行業界で初めて認定されるなど、外部機関からも高い評価を受けています。 3つめは、改善をドライブさせる専任チームがセンターを下支えしている点です。小規模なセンターの場合、改善担当はオペレーションチームが兼務することが多いですが、GMO-PGでは会社や業界のスピードにキャッチアップできるよう改善に向けた専任チームを設けています。 4つめは、メンバーのスキルレベルを見える化することにより、多様なキャリアパスを用意している点です。田中は「エンジニア出身者の多いテクニカルサポートや改善専任チームへの異動など、サポートを1つのサービスとして向上していけるようさまざまな職務がある」と説明します。 5つめは、「とにかく明るいサポートセンター」である点です。センターでは「ありがとう」「笑顔」「素直さ」を行動指針にしており、田中によると「笑顔が絶えないスタッフが揃っており、センター内には常に良い雰囲気が流れている」といいます。 技術的な内容に特化した対応を行う「テクニカルサポートG」 続いて、佐山がテクニカルサポートGの活動について紹介しました。 開発職としてキャリアをスタートした佐山は、顧客の声を聞くことができ、なおかつエンジニアの背景をいかせる職場としてテクニカルサポート職へ転身。現在は、技術的な問い合わせ対応を中心に加盟店やシステム会社のサポートを行っています。 加盟店が抱える悩みや不安、懸念点はさまざまで、問い合わせ内容も多岐に渡ります。たとえば、「決済処理がエラーとなった」「開発を行ううえでどの仕様書を見ればよいのかわからない」「処理フローの想定に問題はないか」など、回答に技術的な知識や経験が求められる問い合わせも多くあります。 エンジニア未経験者がこれに対応しようとすると、開発部門への確認が毎回必要となり回答に時間がかかる、質問の内容がオペレーターに伝わらない、期待どおりの回答が得られず問題が解決しないなどといった問題が生じます。そこで技術的な内容に特化した対応を行うため誕生したのが、テクニカルサポートGです。エンジニア経験者が多く在籍するテクニカルサポートGの強みについて、佐山は次のように話します。 「エンジニアの経験があるからこそわかる悩みや共感できる部分がある。エンジニアと同じ目線に立つことで、加盟店が抱える問題はもちろん、潜在化している問題を発見し、加盟店のシステム運用をより良くしていくことができる」（佐山） サービス導入から安定稼働に向けてアシストすることも、テクニカルサポートGの業務の1つです。そのため、グループのメンバーが営業同行をすることも多いといいます。営業同行では、加盟店システムの担当者も含めて打ち合わせることで、技術的な質問点も含めた不明点を解消していきます。また、それだけでなく、加盟店から改善の要望を受けた際には、開発部門へその声を届けるという役割もテクニカルサポートGが担っています。佐山は「お問い合わせ対応や営業同行を行うなかで、開発側に改善提案をしてシステムに反映させ、それを加盟店にご利用いただくというサイクルが回っている。私たちが加盟店の声を届ける架け橋となることで、複数部署からサポートする仕組みが形成されている」と機能改善に向けた体制について説明します。 たとえば以前、サービスへの接続方式の1つである「リンクタイプPlus」に対して、エラーメッセージがわかりづらいという声が普段のサポートのやり取りのなかからあがっていました。そこで、カード番号の誤りや利用できない支払い方法が指定されているなど、エラーの原因をより具体的に表示されるよう変更しました。 「加盟店からヒアリングした内容をただ開発に伝えるのではなく、具体的にどのようなメッセージがよいのか、システム処理として無理はないかなど、お互いにとってより良い方法を探すことができた。これはエンジニアとして開発や要件定義を行ってきた経験から為せることだと考えている」（佐山） サポート職に転身して良かったと感じる瞬間は、加盟店から感謝の言葉をもらえたときだという佐山。「自分の行った対応が加盟店のためになったと、自己肯定感を感じられる。感謝の言葉は、自分が作ったシステムを活用してもらえていること以上にモチベーションの向上において効果がある」とやりがいを語りました。 サポートの改善活動を専任で担う「サポート企画G」 土屋はサポート企画Gの取り組みを紹介しました。 独立系SIerや社内SEなどを経て2015年にGMO-PGに入社した土屋は、テクニカルサポートに4年従事した後、現在はサポート企画Gにて主にSalesforce関連の利用設計や改善を担当しています。 サポート企画Gは、土屋の入所当時は存在しなかったグループだったといいます。加盟店、決済手段が年々増えることで、問い合わせ対応のための知識習得への負担が大きくなるという状況を打開するため、2019年に改善に特化したグループとして立ち上がったのがサポート企画Gでした。サポート企画Gの設立前は改善活動にかける時間が部門全体で20%しかありませんでしたが、2022年には40%にまで増えています。 現在サポート企画Gでは、サポートにおける各種数値の管理・分析、FAQ・チャットボットといったセルフサポートサービスの運用改善、顧客満足度アンケートの実施、在宅環境の整備など内部の環境整備、社内ナレッジの運用など、さまざまな取り組みを通じて顧客満足度向上を目指しています。 サポート企画Gでは、お客様がなるべく努力をせずに早い段階で問題解決できる「シフトレフト」を目指す取り組みを行っており、そのうち土屋が「一番大きな取り組み」とするのが、FAQサイトの改善です。土屋の入社当時、FAQサイトには専任担当者がおらず、更新も分析もされていない状況でした。そこで有料のFAQシステムを契約し、実際の問い合わせ内容と突き合わせて不足しているFAQは何か分析できるよう、問い合わせを1件ずつカテゴライズしました。また、同じタイミングでPDFマニュアルのオンライン化を行いました。これによりFAQサイトの参照数は増え、加盟店の数が増えているのにもかかわらず問い合わせ数が減少するという効果があったといいます。 現在のFAQサイトは、そこからさらに改善された3代目のバージョンとなります。2代目で利用していたFAQシステムは従量課金制で、参照数が増えるほど費用がかかってしまう状況だったため、社内ナレッジを一元管理でき、他サービスへの展開も可能な別の汎用的なツールへ移行。現在稼働している3代目のサイトへリニューアルすることとなりました。土屋はこの際にエンジニア経験がいきたと振り返ります。 「移行の際にはエンジニア経験をいかし、データの持ち方など今後の発展も視野に入れた構築設計ができた。テクニカルサポート以外でも、カスタマーサポート部では元エンジニアの経験をいかすチャンスがある」（土屋） 2023年4月からは「KCS（ナレッジ・センター・サービス）」を本格スタートしています。KCSは、米マイクロソフトやオラクルといった先進IT企業が参画する非営利団体サービスイノベーションコンソーシアムが発表した方法論です。 KCSの導入以前、問い合わせを受けた担当者は、自身の知識やドキュメント、マニュアルなどを使って回答していました。しかし、KCSではまずはじめに必ずナレッジを検索し、それを利用して回答するという流れになります。既存のナレッジ内に見つからない場合は、ナレッジを新規に作成します。これにより、新人でもベテランメンバー同様の対応ができるようになるメリットがあります。 「KCSは方法論なので、運用方法やシステム設計は示されていない。方法論を理解したうえで運用ルールを作っていく必要があった。私はルール構築に加え、エンジニア経験をいかしてシステム面も担当。お客様対応にSalesforceを利用しているため、ナレッジもSalesforceで検索作成できるように構築設計した」（土屋） サポート企画Gではこれからも、お客様の満足度向上につながる取り組みを続けていきます。 人材教育を担当しセンターの品質を保つ「コンタクトG」 寺村は、コンタクトGの取り組みについて紹介しました。 アパレル会社での接客経験がある寺村。GMO-PGでは電話対応業務からスタートし、現在はコンタクトGのマネージャー職としてチームメンバーの管理、社内各部署との調整等を担当しています。 技術的な内容を扱うテクニカルサポートGに対し、コンタクトGでは、契約に関する手続きや管理画面などの問い合わせに電話・メール・チャットのマルチチャネルで対応しています。 特徴は、ファーストクラスのキャビンアテンダントや大手百貨店の販売員、5つ星ホテルのブライダル担当者など、ハイクオリティな対応が求められる接客経験者が多く集まっている点です。コンタクトGでは、そうした経験者の知見をいかして、品質管理のための対応評価やそれに基づく人材育成も担っています。 特にエンジニア出身者は接客・顧客対応の経験がない場合も多く、知識が豊富にあってもそれをわかりやすく伝えたり、相手の気持ちや状況に適した形で寄り添いを表現したりすることを不得意に感じる人も多いといいます。寺村は「メンバー1人ひとりと会話をしながら、ウィークポイントや成長スピードにあわせて研修を実施していく」と研修の方針について説明します。 初期研修/導入研修では、わかりやすい研修資料を作成・活用するだけでなく、本人からフィードバックの場を設けて研修内容や流れの整合性を見直すことで、カリキュラムのブラッシュアップを重ねています。以前は研修資料が整っておらず、講師の知識レベルによって内容の偏りがあったといいますが、現在では講師向けの研修も実施し、誰が講師になっても情報に偏りなく必要事項が網羅された研修ができるようなカリキュラムとなっています。 導入研修が終わるとOJTに進みます。実際の電話対応において不明点があった場合には、すぐに相談できるよう近くにリーダー以上の先輩メンバーを配置したシフトが作成されているため安心です。1人で顧客対応をするなかで感じる不明点や、導入研修ではカバーできなかった難しい内容については、個別研修やスキル別研修で補っていきます。配属5か月目をすぎると、毎年実施している対応評価、半期に一度受験する全員共通のテストで個々のウィークポイントを洗い出し、それぞれのメンバーにあわせたフォロー研修を実施していきます。 各人のスキルレベルは、受電件数、音源モニタリングのスコア、スキルテストの点数、メールの承認率、KCSナレッジへの貢献などの達成度によって、5段階で評価されます。寺村は「定量的でわかりやすい目標を設定することで、メンバーのモチベーションにつながる。ランクごとのレベル感が明示できるため、サポート全体のバランスを考える際などマネジメントもやりやすくなるメリットがある」と話します。 こうした取り組みの成果もあり、第三者からの高い評価を得ているカスタマーサポート部。寺村は「連続獲得のプレッシャーはある」と明かしながらも、「モチベーションにつながる面もあるうえ、加盟店にもより安心・信頼して使っていただける」と第三者評価の効果を説明します。そして「優しく思いやりのある対応がサポートにとっては大切。これを念頭においてよりご期待に応えられるよう、さらなる顧客満足度向上を目指していきたい」と今後の展望を語りました。 エンジニア採用実施中！ GMO-PGではエンジニアを積極採用中です。さまざまなバックボーンを持つエンジニアのみなさまの力を必要としています。興味のある方はぜひ採用HPをご覧ください。 また、これまで当社エンジニアが登壇したウェビナーやインタビューは以下にまとまっていますので、併せてご覧ください。https://www.gmo-pg.com/blog/feature/feature03/ さいごに ご視聴・ご参加いただき、ありがとうございました。参加いただいた方からは、御社の取り組みを理解することができました、自らの参考にできる部分があれば取り入れていきたい、教育体制についてとても勉強になりました、興味深かったなど、温かいコメントをたくさんいただき、大変嬉しく思っております。重ねて御礼申し上げます。 映像はアーカイブ公開しておりますので、まだ見ていない方、もう一度見たい方は 是非この機会にご視聴ください！ https://youtu.be/mcgoDy1M9TA

こんにちは。GMOインターネットグループ株式会社の村上です。今回は8月～9月に5週間に渡ってオフラインでのインターンを開催しました。場所はGMOインターネットグループ株式会社 北九州オフィス（GMO kitaQ）で行いました。今年で2回目の開催となりますが、去年のコンテンツから更にパワーアップしてやりごたえのあるインターンの内容をレポートします。 はじめに 各コースと日程 去年と同様にアプリケーション開発コース、インフラコースに関しては1週間✕2回を実施。セキュリティコースは前年1dayのコースも準備していましたが、より専門性を高める為に今回は5daysのコースのみになりました。参加学生数は各コース20名前後、全体で100名を超える学生さんたちに参加いただきました。 開催場所 開催場所は福岡県北九州市小倉にある「GMO kitaQ」オフィスのyoursスペースを貸し切ってオフライン開催しました。交通費・インターン期間中の宿泊費は全額GMOで負担し、全力でインターン取り組んでもらえるようにしました。 各コース毎のコンテンツ詳細 Webアプリケーション開発コース 去年と同様に各チームで課題に対してユーザーストーリーを考え、開発を行っていくハッカソン型をコンセプトとしました。要件定義から行い画面仕様・詳細仕様を作成し、アプリケーションの実装後Webサーバーにデプロイして公開してもらいました。 各チーム考えていただいた要件は自身のチームで作成するのではなく、他のチームに作ってもらいます。これにはちゃんと理由があって、基本的にシステムサイドが新たに作りたい機能を作る、というよりは事業やサービスについて考えるチームがいて、そのチームから要件という形で依頼がきてシステム開発が始まっていきます。なので今回のハッカソンもそのアプリケーションがほしいと考える人の要求に答える形で開発をすすめてもらいました。 他のコースとは違い座学等はなく、基本的にはチームの中で話し合い役割分担を行ってからアプリケーションの開発を行っていきます。短い期間で要求されたアプリケーションを作るのはかなり難しいと思いますが、各チームしっかりとコミュニケーションを取って、要求に答えるアプリケーションを作成していました。意外と勘違いされがちなのですが、アプリケーションエンジニア（プログラマ）はひたすらPCに向かってコーディングしていくイメージを持ってる人がいますが、チームで開発するので周りとコミュニケーションを取ることが大事になります。 今回のインターンではアイスブレイクでマシュマロチャレンジを題材にしたワークショップを行いました。マシュマロチャレンジを通して課題解決思考の理解とその実践を行います。みなさん非常に優秀でチームで協力して最初からかなりいい記録を出しているチームもいました。 しっかりとコミュニケーションを取り、チーム一丸となって開発したアプリケーションはどれも非常に良くできていていました。終わった後は疲れているながらもみんないい笑顔でした！ インフラコース インフラエンジニアと一言で言っても、その業務は多岐に渡ります。イメージがつきやすいアプリケーションエンジニア（プログラマ）と違って、世間一般に「地味そう、つまらなそう、仕事のイメージがつかない」等、あまりよいイメージを聞きません。また企業によってもその業務内容は異なります。 そこで今回は弊社でのインフラエンジニアはどのような業務があるのか知ってもらうために ConoHaの開発工程をインフラエンジニアの立場で体験しよう！ をテーマにインターンを開催しました。 弊社の主要商材であるConoHaをベースにそれに関わる業務を体験することで、GMOインターネットグループにおけるインフラエンジニアの職種と役割を知り、自身の目指したいエンジニア像を明確化することをゴールとするコンテンツとしました。 アイスブレイク いま話題の画像生成AI(Stable Diffusion)を使って、各チームのオリジナルのフラッグ作成に挑戦してもらいました。（参考記事はこちら→https://developers.gmo.jp/37652/） 条件は チーム名（A～F）のアルファベットを含むチームメンバーの好きな要素を加える チームでプロンプトをどのようにするか、どのデザインにするか活発に意見が交わされていました。その結果、みなさんが自然とコミュニケーションを取るようになり、和気あいあいとした雰囲気に。 1　ConoHaの企画・設計思想について知ろう！ 新規サービス立ち上げに関連する企画・設計段階の考慮点や技術選定について、実際に関わったパートナーから講義を受けました。みなさんメモを取りながら熱心に耳を傾けていました。 2　ハードウェアに触れよう！ 各チーム毎に１台ラックサーバを用意し、ハードウェアの取り付けやリモート管理ツール、RAIDの構築等、普段触れないような作業を体験しました。電源を入れてもうまく起動しない等のトラブルが発生した際も、みんなで解決し、楽しそうに活動していました。 3　ネットワークを構築しよう！ 実際のネットワーク機器にログインし、通信ができるように設定する体験も。さらに、弊社のネットワークを支えるエンジニアからのプレゼンテーションも大好評で、質問が絶えませんでした。 4　仮想基盤を構築しよう！ LinuxOSから仮想環境（KVM）の構築までを行いました。クラウド上で簡単にできるVM作成もコマンドラインで行うことで、インフラ基盤の動きを間近で感じられ、より深い理解が得られました。 5　ConoHaの課金の仕組みを体験しよう！ ConoHaで利用されている課金の技術について解説し、チーム毎に課金方針を検討して金額を取得するまで体験しました。インフラエンジニアの仕事が多岐にわたることに、多くの参加者が驚いていました。 6　作ったシステムを監視してみよう！ 作成したシステムを実際に監視ツールで監視し、アラートを出してもらいました。監視の必要性について理解し、「研究室のサーバに監視設定してみたい」といった声が聞かれました。 7　問い合わせ対応を体験しよう！ お客様からの問い合わせにどう対応するか、ログ解析から回答までを実際に体験。新たな面白みを感じる参加者が多かったです。 インターンシップを通して「インフラエンジニアってこんなに面白い！」と感じ、最終日には参加者全員が目指すインフラエンジニアの具体的なキャリアイメージもできたようです。 皆さんにとって有意義な時間となり、高評価をいただきました。 セキュリティコース セキュリティコースでは、インシデントハンドリングとアイデアソンという2つのコンテンツを実施しました。今回のインターンのテーマは「答えのない課題に対してチームで組む(理解力×思考力×発言力×調整力×表現力)」でした。セキュリティに関わるお仕事は、1人では出来ず、他チーム・他部署と連携して進める事が多くあります。そのため、コミュニケーション能力や思考力などが必須になります。その事を実感してもらえるものとして先述した2つのコンテンツにしました。 それでは、各コンテンツについて少し紹介します。 インシデントハンドリング 実際にインシデントが起こったとき会社の中でどのような対応をするべきか机上演習を通して理解を深めます。1回やって終わりでは理解も深まらないので複数セット繰り返して徐々に難易度を上げていくようにしました。 初回は、前提として会社とシステムの構成図を提供しインシデント発生報告をトリガーとしてハンドリングが始まります。インターン生は全員Blueチームとしてシステム部署にログ調査を依頼し攻撃の有無を確認したり、事業部側にインシデントの事実確認や通報元などRedチームから出てきた情報からインシデントの発生個所や被害の規模、インシデント後の対応を考えます。 2回目以降はシステムの構成図が複雑になったり、RedチームとしてBlueチームからの調査結果の回答をする立場になったり、システムの構成図とインシデントそのものを問題として作成して他チームに解いてもらうなど徐々に難しくなっていきます。インターン生を見ていると自分でインシデントを考えるところが難しく、よりリアルで発生しそうな事例や自分の好きな機器や脆弱性からヒントを得たインシデントなどチームによって様々なパターンを考えディスカッションに花が咲いていました。 アイデアソン あるテーマに対してチームで議論し内容をまとめて発表します。正解のないお題に対して考える思考力やチームで議論することでコミュニケーション能力を向上させます。限られた時間の中で案出し～まとめ～発表用資料作成を行うためのフレームワークを紹介しそれに沿って進めていきます。テーマはセキュリティに関連するものはもちろん生成AIを活用したツールを会社で導入する際の懸念点とルール作りについてなど複数用意しました。 アイデアソンもインシデントハンドリングと同様に複数セット繰り返すことでフレームワークの定着と思考力の向上を図りました。 今回のセキュリティインターンでは技術を中心にするのではなく、インターン生同士で議論するという内容だったのでインターン生同士の仲も深まり、お互いの就活や研究分野の共有なども活発でお互いに良い刺激になっていたようでした。 さいごに 去年に引き続き全てのコースで参加いただいた学生さんたちのレベルは非常に高く、全員が意欲的にインターンに取り組んでいただけてとてもよかったです。去年よりも一部コンテンツのブラッシュアップにより難易度も上がっていましたが、それでもしっかりとついてこれていました。また去年課題でもあった、「GMOを知ってもらう」「エンジニアのことを知ってもらう」ということに重点をおいたコミュニケーションを取れる時間を作ったおかげで、参加いただいた学生のみなさんもよりGMOのこと、エンジニアのことを知ってくれたんじゃないかなと考えてます。 終了後のアンケートでも、全員が満足だったという回答をいただき準備した方としてもとても嬉しい結果となりました。また、メンターにもアンケートを取ったところ、学生さんたちから非常にモチベーションをもらえたという回答を多くもらいました。 今回は25卒の学生さんが対象だったので、全員がこれから就職活動を始めていく時期だと思います。今回インターンに参加して、同年代の友人もたくさんできたと思いますので、このつながりを大事にして大変な就職活動を乗り切っていってください。現在GMOインターネットグループでは新卒採用が始まっていますので、インターン参加できた学生さんやそうでない方も、興味を持っていただけたらぜひエントリーをお待ちしております。 GMOインターネットグループ 2025新卒採用マイページhttps://mypage.3150.i-webs.jp/gmo2025/

今年もPHPカンファレンスにスペシャルスポンサーとして協賛いたします！GMOインターネットグループ独自企画も実施予定で、イベント限定ノベルティもご用意しております。ぜひご参加ください。 PHP Conference Japan とは PHPカンファレンスは1999年から開催しているPHP関連の技術を主とした技術者カンファレンスです。今年は完全リアル開催となります。 イベント概要 開催日時：2023年10月8日（日）10:00～19:00会　　場：大田区産業プラザPiO主　　催：日本PHPユーザ会公式ＨＰ：https://phpcon.php.gr.jp/2023/ GMOインターネットグループからは3名登壇！ スポンサーセッション　10/8（日）12:40-13:30 @Track1 「ConoHaの課金元データ収集バッチの進化と軌跡」GMOインターネットグループ株式会社　瀬戸 悠平 OpenStackを利用しているConoHaの課金において重要な役割を果たすシステムの一部に焦点を当てます。このセッションでは、OpenStack Ceilometerを利用した課金の元データ収集バッチの進化と軌跡について詳しくご紹介します。課金を計測するための元データを作成する本バッチは、バージョン3の稼働を目前に控えています。バージョン1の引き継ぎから始まり、自身が直面した課題や感じたこと、バージョンアップに向けた改善への挑戦を共有します。さらに、バージョン3での変更点や進化についても紹介し、ConoHaの課金元データ収集バッチの成長の軌跡をお伝えします。 ■セッション詳細：https://fortee.jp/phpcon-2023/proposal/196a5410-96d5-470c-a975-1fba619c33e7 レギュラートーク　10/8（日）13:45-14:35 @Track2 「スケーラブルサービス――疎結合に成長するシステムに不可欠な要素」GMOインターネットグループ株式会社 デベロッパーエキスパート　成瀬 允宣 本セッションでは拡張性に重きを置いたシステムについてお話しします。マイクロサービス・モジュラモノリスとアーキテクチャスタイルは多様化していますが、重要なのはスタイルではありません。本セッションではスケーラビリティを重視します。スケーラビリティはリソース・コード・組織など様々な観点があり、それらのスケーラビリティの向上はいずれもビジネスにポジティブなインパクトを与えます。本セッションではそれらを担保するために必要な要素が何かを深堀りし、それらを実現する具体的な技術スタックやアーキテクチャを模索します。その中でPHPを主軸としたとき、活用しやすい箇所・しづらい箇所についても言及します。得られる知識：スケーラビリティの多面的な観点の理解スケーラビリティを担保する重要な要素とその実現方法スケーラブルなシステムを実現するための実践的な知識と洞察 ■セッション詳細：https://fortee.jp/phpcon-2023/proposal/d81f49cf-009c-4953-af24-1582a827edef LT　10/8（日）16:55-17:00 @Track1 「これから始める！ニ段飛ばしのPHPバージョンアッププロジェクト戦略」GMOペパボ株式会社　matsusuke  現在、私はPHP5.2で稼働しているレガシーアプリケーションのバージョンを最新の8.2に上げるプロジェクトに参加しています。このプロジェクトは、7系へのバージョンアップをスキップするという挑戦的なプロジェクトで、さらに、現状は使用中のフレームワークが古かったり、テストがほとんど書かれていないという状況でもあります。このような制約がある中で、「バージョンを8.2に上げて、アプリケーションを問題なく動かす」という目的を達成するために私が今考えている戦略についてお話しします。このプロジェクトは今まさに進行中であるため、もっといい案があったり同じような課題を解決したことがある方がいれば助けていただけると嬉しいです！バージョンアップのプロジェクトは多くの企業で共通の課題であるため、お話しする内容が皆さんの取り組みの一助となれば幸いです！ ■セッション詳細：https://fortee.jp/phpcon-2023/proposal/85118c7f-c8ab-4c53-a99f-6566306404e4 今年もやります！GMOインターネットグループ独自企画 GMOインターネットグループブース「ConoHaアドベンチャー」 今回のテーマは「アドベンチャー」砂漠エリア、泉エリア、火山エリアそれぞれアクションを実行しながらこのはと冒険しよう！クイズに答えて正解すると、PHPcon2023限定ノベルティグッズがもらえるよ！ 今回は2キャラクターのコラボデザインとなります！ ElePHPant：PHPのマスコットキャラクター美雲このは：GMOインターネットグループ株式会社｜レンタルサーバー、VPS、Windows Serverなどのホスティングサービス「ConoHa」のキャラクター 会場参加される方はぜひGMOインターネットグループのブースにも足を運んでくださいね！ さいごに 完全オフライン開催となる今回、みなさまにリアルでお会いできますこと、楽しみにしております！

本記事はGMOインターネットグループで複数ある開発者ブログのなかから人気の記事をピックアップして再掲載しています。機械学習や深層学習のビジネス応用を研究、社会実装をしているグループ研究開発本部 AI研究開発室のデータサイエンティストが寄稿した人気記事です。 結論ファースト A. ベクターストアに入れる元ネタドキュメントの抽出⇒ unstructured が使えるかも B. ベクターストアに入れる元ネタドキュメントのチャンク分け⇒ タイトル。キーワードをメタデータで付加 C. ベクターストアに投げる質問プロンプトの最適化⇒ 形態素またはキーワード抽出でプロンプトを精査 D. ベクターストア検索結果の精査⇒ ContextualCompressionRetriever による検索結果要約とDocumentCompressorPipeline による検索結果絞り込みがよさげ「検索結果が質問に沿ったものか精査させる」タスクをChatGPTに担当してもらうことが私の業務課題には適しているのではという気付きがありました。 E. （おまけ）ベクターストアの選定⇒ 1位はFaiss。マネージドも多々あり。Chromaがこれから来るかも。 ChatGPT 活用に関する問題意識 プロジェクト管理者にとっての ChatGPT 活用 ChatGPT はシステム開発の現場でも非常に役に立っていますが、現在の利用範囲は「個別のコードの生成」や「レビュー」など、どちらかというと小さく限定されたタスクが多いと思います。 私はプロジェクト管理をしている立場なので、自分自身の業務で ChatGPT を活かすにはもっと広い視点でアイディアを出す必要性を感じています。最終的には以下のような業務に ChatGPT を活用できないかと日々妄想し、勉強会や Web 検索に勤しんでいます。 指定した仕様でプロジェクトのコードを実装してもらう。ソースコードを読み込んで仕様に関するQAを回答する。仕様に関するドキュメントを読み込んでソースレビューをする。既存ソースコードを読み込んでソースレビューをする。ソースコードや仕様ドキュメントを読み込んで該当機能の影響範囲を特定する。 今回は「影響範囲の調査」にフォーカスして考えてみようと思います。まだ道半ばですが、現在わかっている手法のいくつかをご紹介していきます。 In-Context Learning を突き詰める必要性 2023年7月の公式発表で ChatGPT 3.5 Turbo と 4 の Fine Tuning が2023年後半に利用可能になるかもという情報が公表されました。 "We are working on safely enabling fine-tuning for GPT-4 and GPT-3.5 Turbo and expect this feature to be available later this year."「私たちは GPT-4 および GPT-3.5 Turbo の微調整を安全に有効にすることに取り組んでおり、この機能は今年後半に利用可能になる予定です。」https://openai.com/blog/gpt-4-api-general-availability Fine Tuning は ChatGPT に特定の知識を身に着けさせる「追加学習」です。こちらに関してまだ古いモデルである GPT3 でしか提供されておらず事例も少なくなっており、わかっていないことがたくさんあります。1つの疑念として、 ChatGPT は少しの情報を与えた程度では専門的な知識を覚えてくれないのではというのがあります。例えば、自社のシステム仕様情報を Fine Tuning で覚えさせても、そもそもの元の学習データには似たような情報が膨大に入っており、そちらに引っ張られて結局一般的なことを回答してしまう、もっと言うとありもしない幻覚を回答するリスクはどこまでいっても残り続ける可能性があるのではという話を聞きました。Fine Tuning とは別のアプローチとして、「都度学習」 としての In-Context Learning があります。これはプロンプトに都度必要な情報を全部含めてしまうことでChatGPTが正確な回答を生成しやすくするという手法です。現状は Fine Tuning の可能性が不透明なことから、In-Context Learning を突き詰めて精度を向上していく必要性が当面は継続するという見方もできると考えています。 In-Context Learning の事例は巷に溢れており（現実的に2023年7月現在はこれしか有効な手法がないというのがある）、特に Python では LangChain や Llamaindex などのフレームワークがありますが、結局は「 ChatGPT のプロンプトの中に別のデータソースから得た情報を埋め込んでいく」という手法に集約されます。 私のプロジェクト管理業務の改善に大きく関連する話では Pinecone 社が出している以下の事例が興味深いです。 GPT4にLangChainのソースコードに関する質問を回答させるhttps://github.com/pinecone-io/examples/blob/master/generation/gpt4-retrieval-augmentation/gpt-4-langchain-docs.ipynb 本質的にはこれに近いことを自社のプロジェクトの仕様ドキュメント＋ソースコードで実現したい、というのが現在の私の目指すゴールになると思います。 In-Context Learning で利用するベクターストアの現実的な課題 LangChain でも Llamaindex でも内部的に外部データソースで情報検索をすることで In-Context Learning を実現しています。このデータソースの実現方法はいくつかあるのですが、特に特定のプロジェクトの情報を格納する目的では自前でのベクターストア構築が本命になると思います。ベクターストアは文書をベクトル化して保存し検索された単語との関連度を高速に判定することで精度の高い検索ができる検索エンジンです。（種類はいくつかあるので終盤で少し紹介します） ただ、ベクターストアは検索エンジンのため、その活用にあたり以下のような初期的な課題に直面します。（今回のメインコンテンツです） A. ベクターストアに入れる元ネタドキュメントの抽出B. ベクターストアに入れる元ネタドキュメントのチャンク分けC. ベクターストアに投げる質問プロンプトの最適化D. ベクターストアからのレスポンス精査E. （おまけ）ベクターストアの選定 ここからこれらひとつひとつをどのように解決できるか、調査・検証した内容をご紹介していきます。 A. ベクターストアに入れる元ネタドキュメントの抽出 ここでいう元ネタドキュメントは、仕様情報やソースコードなど ChatGPT が few shot の In-Context Learning のためにプロンプトに入れて送る情報です。まずはベクターストアに登録する事前準備として、この元ネタドキュメント情報をプログラムから扱いやすいように抽出・整形する必要があります。 unstructured ライブラリ 私の担当には Atlassian の Confluence を使って仕様ドキュメントを管理しているプロジェクトがあり、こちらはページ全体を HTML または PDF で出力できます。HTMLまたはPDFのドキュメントをどうやってパースしてテキストドキュメント化するのかという課題がありますが、 unstructured という Python ライブラリがありました。 公式ページhttps://www.unstructured.io/ こちらを使うと PDF、HTML だけでなく Excel や md からのドキュメントからでも個別のプレーンなテキストを生成できます。対応しているドキュメント種別は公式に記載があります。https://unstructured-io.github.io/unstructured/bricks.html#partitioning 具体例として、弊社 VPS サービスの Conoha API ドキュメントをHTMLとPDFにして練習してみます。トークン取得APIhttps://www.conoha.jp/docs/identity-post_tokens.php コードは至ってシンプルです。 from unstructured.partition.html import partition_html elements = partition_html("conoha_api_token.html") print("\n\n".join([str(el) for el in elements])) HTMLからドキュメントを抽出した結果（長いので折りたたまれています） MENU TOP Identity API v2.0 バージョン情報取得 バージョン情報詳細取得 トークン発行 Account(Billing) API v1 バージョン情報取得 バージョン情報詳細取得 アイテム一覧の取得 アイテム詳細取得(アイテム指定) 入金履歴取得 入金サマリー取得 請求データ一覧取得 請求データ明細取得(アイテム指定) 告知一覧取得 告知詳細取得(アイテム指定) 告知既読・未読変更 Object Storage 利用状況グラフ(リクエスト数) Object Storage 利用状況グラフ(使用容量数) Compute API v2 バージョン情報取得 バージョン情報詳細取得 VMプラン一覧取得 VMプラン詳細取得 VMプラン詳細取得(アイテム指定) VM一覧取得 VM一覧詳細取得 VM詳細取得（アイテム指定) VM追加 VM削除 VM起動 VM再起動 VM強制停止 VM通常停止 OS再インストール VMリサイズ VMリサイズ（confirm） VMリサイズ（revert） VNCコンソール ローカルディスクのイメージ保存 ストレージコントローラー変更 ネットワークアダプタ変更 ビデオデバイスの変更 コンソールのキーマップ変更 WebSocket(novaconsole)用のAPI WebSocket(httpconsole)用のAPI ISOイメージの挿入（mount） ISOイメージの排出（unmount） セキュリティグループのサーバへの割り当て状態表示 キーペア一覧取得 キーペア詳細取得(アイテム指定) キーペア追加 キーペア削除 イメージ一覧取得(nova) イメージ詳細取得 イメージ詳細取得(アイテム指定)(nova) アタッチ済みボリューム一覧 アタッチ済みボリューム取得（アイテム指定) ボリュームアタッチ ボリュームデタッチ アタッチ済みポート一覧取得 アタッチ済みポート取得（アイテム指定) ポートアタッチ ポートデタッチ VMメタデータの更新（ネームタグの変更） VMメタデータ取得 VMに紐づくアドレス一覧 VMに紐づくアドレス一覧(ネットワーク指定) VPS利用状況グラフ（CPU使用時間） VPS利用状況グラフ（インターフェイストラフィック） VPS利用状況グラフ（ディスクIO） バックアップ一覧取得 バックアップ一覧取得(backup id 指定) バックアップの申し込み バックアップの解約 ブートディスクバックアップのリストア ブート・追加ディスクバックアップのイメージ保存 ISOイメージの一覧 ISOイメージダウンロード Block Storage API v2 バージョン情報取得 バージョン情報詳細取得 ボリュームタイプ一覧取得 ボリュームタイプ取得（アイテム指定) ボリューム一覧取得 ボリューム詳細取得 ボリューム詳細取得（アイテム指定) ボリューム作成 ボリューム作成（ソースボリューム指定） ボリューム削除 ブロックディスクのイメージ保存 Image API v2 バージョン情報取得 イメージ一覧取得(Glance) イメージ詳細取得(アイテム指定)(glance) イメージコンテナのスキーマ情報取得 イメージのスキーマ情報取得 イメージメンバーコンテナのスキーマ情報取得 イメージメンバーのスキーマ情報取得 イメージメンバー一覧取得 イメージ削除 イメージ保存容量制限 イメージ保存容量制限情報取得 Network API v2.0 バージョン情報取得 バージョン情報詳細取得 ネットワーク一覧取得 ネットワーク詳細取得 ネットワーク追加(ローカルネット用) ネットワーク削除 ポート一覧取得 ポート詳細取得 ポート追加 ポート更新 ポート削除 サブネット一覧取得 サブネット詳細取得 サブネットの払い出し(ローカルネット用) サブネットの払い出し(追加IP用) サブネットの払い出し(LB用) サブネットの削除 POOL一覧取得 POOL詳細取得 POOL追加（バランシング指定） POOL更新(バランシング方式の変更) POOL削除 VIP一覧取得 VIP詳細取得 VIP作成 VIP削除 REAL（member）一覧取得 REAL（member）詳細取得 REAL（member）追加 REAL(member)更新 REAL(member)削除 ヘルスモニタ一覧取得 ヘルスモニタ詳細取得 ヘルスモニタ作成 ヘルスモニタ変更 ヘルスモニタ削除 ヘルスモニタの関連付け ヘルスモニタの関連付け解除 セキュリティグループ一覧取得 セキュリティグループ詳細取得 セキュリティグループ作成 セキュリティグループ更新 セキュリティグループ削除 セキュリティグループ ルール一覧取得 セキュリティグループ ルール詳細取得 セキュリティグループ ルール作成 セキュリティグループ ルール削除 ObjectStorage API v1 アカウント情報取得 アカウントクォータ設定 コンテナ情報取得 コンテナ作成 コンテナ削除 オブジェクト情報取得 オブジェクトアップロード オブジェクトダウンロード オブジェクト複製 オブジェクト削除 dynamic large objects static Large Object object versioning schedule objects for deletion temporary url middleware web publishing Database API v1 バージョン情報取得 バージョン情報詳細取得 サービス作成 サービス一覧取得 サービス情報取得 サービス更新 サービス削除 サービスメタデータ更新 データベース上限値取得 データベース上限値変更 バックアップ有効無効 データベース作成 データベース一覧取得 データベース情報取得 データベース更新 データベース削除 データベース権限作成 データベース権限一覧取得 データベース権限削除 バックアップ一覧 リストア アカウント作成 アカウント一覧取得 アカウント情報取得 アカウント更新 アカウント削除 DNS API v1.0 バージョン情報取得 ドメインホスティング情報表示 ドメイン一覧表示 ドメイン作成 ドメイン削除 ドメイン情報表示 ドメイン更新 レコード一覧取得 レコード作成 レコード削除 レコード情報表示 レコード更新 ゾーンファイルインポート ゾーンファイルエクスポート ConoHa API Documantation トークン発行 - Identity API v2.0 トークン発行 - Identity API v2.0 TOP Identity API v2.0 バージョン情報取得 バージョン情報詳細取得 トークン発行 Account(Billing) API v1 バージョン情報取得 バージョン情報詳細取得 アイテム一覧の取得 アイテム詳細取得(アイテム指定) 入金履歴取得 入金サマリー取得 請求データ一覧取得 請求データ明細取得(アイテム指定) 告知一覧取得 告知詳細取得(アイテム指定) 告知既読・未読変更 Object Storage 利用状況グラフ(リクエスト数) Object Storage 利用状況グラフ(使用容量数) Compute API v2 バージョン情報取得 バージョン情報詳細取得 VMプラン一覧取得 VMプラン詳細取得 VMプラン詳細取得(アイテム指定) VM一覧取得 VM一覧詳細取得 VM詳細取得（アイテム指定) VM追加 VM削除 VM起動 VM再起動 VM強制停止 VM通常停止 OS再インストール VMリサイズ VMリサイズ（confirm） VMリサイズ（revert） VNCコンソール ローカルディスクのイメージ保存 ストレージコントローラー変更 ネットワークアダプタ変更 ビデオデバイスの変更 コンソールのキーマップ変更 WebSocket(novaconsole)用のAPI WebSocket(httpconsole)用のAPI ISOイメージの挿入（mount） ISOイメージの排出（unmount） セキュリティグループのサーバへの割り当て状態表示 キーペア一覧取得 キーペア詳細取得(アイテム指定) キーペア追加 キーペア削除 イメージ一覧取得(nova) イメージ詳細取得 イメージ詳細取得(アイテム指定)(nova) アタッチ済みボリューム一覧 アタッチ済みボリューム取得（アイテム指定) ボリュームアタッチ ボリュームデタッチ アタッチ済みポート一覧取得 アタッチ済みポート取得（アイテム指定) ポートアタッチ ポートデタッチ VMメタデータの更新（ネームタグの変更） VMメタデータ取得 VMに紐づくアドレス一覧 VMに紐づくアドレス一覧(ネットワーク指定) VPS利用状況グラフ（CPU使用時間） VPS利用状況グラフ（インターフェイストラフィック） VPS利用状況グラフ（ディスクIO） バックアップ一覧取得 バックアップ一覧取得(backup id 指定) バックアップの申し込み バックアップの解約 ブートディスクバックアップのリストア ブート・追加ディスクバックアップのイメージ保存 ISOイメージの一覧 ISOイメージダウンロード Block Storage API v2 バージョン情報取得 バージョン情報詳細取得 ボリュームタイプ一覧取得 ボリュームタイプ取得（アイテム指定) ボリューム一覧取得 ボリューム詳細取得 ボリューム詳細取得（アイテム指定) ボリューム作成 ボリューム作成（ソースボリューム指定） ボリューム削除 ブロックディスクのイメージ保存 Image API v2 バージョン情報取得 イメージ一覧取得(Glance) イメージ詳細取得(アイテム指定)(glance) イメージコンテナのスキーマ情報取得 イメージのスキーマ情報取得 イメージメンバーコンテナのスキーマ情報取得 イメージメンバーのスキーマ情報取得 イメージメンバー一覧取得 イメージ削除 イメージ保存容量制限 イメージ保存容量制限情報取得 Network API v2.0 バージョン情報取得 バージョン情報詳細取得 ネットワーク一覧取得 ネットワーク詳細取得 ネットワーク追加(ローカルネット用) ネットワーク削除 ポート一覧取得 ポート詳細取得 ポート追加 ポート更新 ポート削除 サブネット一覧取得 サブネット詳細取得 サブネットの払い出し(ローカルネット用) サブネットの払い出し(追加IP用) サブネットの払い出し(LB用) サブネットの削除 POOL一覧取得 POOL詳細取得 POOL追加（バランシング指定） POOL更新(バランシング方式の変更) POOL削除 VIP一覧取得 VIP詳細取得 VIP作成 VIP削除 REAL（member）一覧取得 REAL（member）詳細取得 REAL（member）追加 REAL(member)更新 REAL(member)削除 ヘルスモニタ一覧取得 ヘルスモニタ詳細取得 ヘルスモニタ作成 ヘルスモニタ変更 ヘルスモニタ削除 ヘルスモニタの関連付け ヘルスモニタの関連付け解除 セキュリティグループ一覧取得 セキュリティグループ詳細取得 セキュリティグループ作成 セキュリティグループ更新 セキュリティグループ削除 セキュリティグループ ルール一覧取得 セキュリティグループ ルール詳細取得 セキュリティグループ ルール作成 セキュリティグループ ルール削除 ObjectStorage API v1 アカウント情報取得 アカウントクォータ設定 コンテナ情報取得 コンテナ作成 コンテナ削除 オブジェクト情報取得 オブジェクトアップロード オブジェクトダウンロード オブジェクト複製 オブジェクト削除 dynamic large objects static Large Object object versioning schedule objects for deletion temporary url middleware web publishing Database API v1 バージョン情報取得 バージョン情報詳細取得 サービス作成 サービス一覧取得 サービス情報取得 サービス更新 サービス削除 サービスメタデータ更新 データベース上限値取得 データベース上限値変更 バックアップ有効無効 データベース作成 データベース一覧取得 データベース情報取得 データベース更新 データベース削除 データベース権限作成 データベース権限一覧取得 データベース権限削除 バックアップ一覧 リストア アカウント作成 アカウント一覧取得 アカウント情報取得 アカウント更新 アカウント削除 DNS API v1.0 バージョン情報取得 ドメインホスティング情報表示 ドメイン一覧表示 ドメイン作成 ドメイン削除 ドメイン情報表示 ドメイン更新 レコード一覧取得 レコード作成 レコード削除 レコード情報表示 レコード更新 ゾーンファイルインポート ゾーンファイルエクスポート Description 有効なトークン情報を取得する Request URL Request Paramters username ユーザー名 plain ユーザ名 password ユーザーパスワード plain ユーザパスワード tenantId (Optional) Tenant ID plain テナントID Request Json Normal response codes 200 OK Example※エンドポイントURLにつきましては、お客様環境によって異なりますので、コントロールパネルにてご確認の上ご利用ください。 REQ RES ConoHa WING トップ 料金・仕様 特長 機能 ドメイン ご利用の流れ 導入事例 お申し込み ConoHa VPS トップ 料金・仕様 特長 機能 ご利用の流れ 導入事例 お申し込み ConoHa for Windows Server トップ 料金・仕様 特長 ご利用の流れ お申し込み ConoHa for GAME トップ 料金・仕様 特長 ご利用の流れ お申し込み おすすめ情報 ConoHa Mobile ConoHaカード ConoHa学割 ConoHaデビュー割 採用情報 美雲このはオフィシャルサイト ワプ活 マイクラゼミ 美雲このは徹底ガイド サポート トップ ConoHa WINGサポート ConoHa VPSサポート ConoHa for Windows Serverサポート 用語集 会員規約 ConoHaドメイン登録規約 ConoHaチャージ利用規約 ConoHaクーポン利用規約 特定商取引法に基づく表記 資金決済法に基づく表示 サービス品質保証制度(SLA) お問い合わせ プライバシーポリシー Cookieポリシー 会社概要 Copyright © 2023 GMO Internet Group, Inc. All Rights Reserved. from unstructured.partition.pdf import partition_pdf elements = partition_pdf("conoha_api_token.pdf") print("\n\n".join([str(el) for el in elements])) PDFからドキュメント抽出結果（長いので折りたたまれています） トークン発⾏ - Identity API v2.0｜ConoHa API 法⼈⼝座即⽇ > GMOあおぞらネット銀⾏ CFD国内1位 > GMOクリック証券 国内1位 > 電⼦印鑑GMOサイン 夢を応援 > 起業の窓⼝ byGMO ConoHa API Documantation トークン発行 - Identity API v2.0  トークン発行 - Identity API v2.0 Description TOP 有効なトークン情報を取得する Identity API v2.0  バージョン情報取得 バージョン情報詳細取得 Request URL トークン発行 Account(Billing) API v1  identity API v2.0 Compute API v2  POST /v2.0/tokens Block Storage API v2  Image API v2  Network API v2.0 Request Paramters  ObjectStorage API v1  Parameter Value Style Description Database API v1  username ユーザー名 plain ユーザ名 DNS API v1.0  password ユーザーパスワード plain ユーザパスワード tenantId (Optional) Tenant ID plain テナントID Request Json { "auth": { "passwordCredentials": { "username": "ConoHa", "password": "paSSword123456#$%" }, "tenantId": "487727e3921d44e3bfe7ebb337bf085e" } } Normal response codes 200 OK Example ※エンドポイントURLにつきましては、お客様環境によって異なりますので、コン トロールパネルにてご確認の上ご利用ください。 REQ curl -i -X POST \ H "Accept: application/json" \ d '{"auth":{"passwordCredentials":{"username":"ConoHa","password":"paSSword123456#$%"}," https://identity.tyo1.conoha.io/v2.0/tokens RES HTTP/1.1 200 OK Date: Mon, 08 Dec 2014 02:40:56 GMT Server: Apache Content-Length: 4572 Content-Type: application/json { "access": { "token": { "issued_at": "2015-05-19T07:08:21.927295", "expires": "2015-05-20T07:08:21Z", "id": "sample00d88246078f2bexample788f7", "tenant": { "name": "example00000000", "enabled": true, "tyo1_image_size": "550GB", } ], "endpoints_links": [], "type": "mailhosting", "name": "Mail Hosting Service" }, { "endpoints": [ { "region": "tyo1", "publicURL": "https://dns-service.tyo1.conoha.io" } ], "endpoints_links": [], "type": "dns", "name": "DNS Service" }, { "endpoints": [ { "region": "tyo1", "publicURL": "https://object-storage.tyo1.conoha.io/v1/nc_a4392c0ccba74485abd } ], "endpoints_links": [], "type": "object-store", "name": "Object Storage Service" }, { "endpoints": [ { "region": "sjc1", "publicURL": "https://identity.sjc1.conoha.io/v2.0" }, { "region": "tyo1", "publicURL": "https://identity.tyo1.conoha.io/v2.0" }, { "region": "sin1", "publicURL": "https://identity.sin1.conoha.io/v2.0" } ], "endpoints_links": [], "type": "identity", "name": "Identity Service" } ], "user": { "username": "example00000000", "roles_links": [], "id": "examplea6963c074d7csample12a886ee", "roles": [ { "name": "SwiftOperator" }, { "name": "_member_" } ], "name": "example00000000" }, "metadata": { "is_admin": 0, "roles": [ "0000000000000000000000000000000e", "11111111111111111111111111111113" ] } } } ConoHa for Windows Server ConoHa WING ConoHa VPS ConoHa for GAME おすすめ情報 サポート トップ トップ トップ トップ ConoHa Mobile トップ       料金・仕様 料金・仕様 料金・仕様 料金・仕様 ConoHaカード ConoHa WINGサポー       ト 特長 特長 特長 特長 ConoHa学割  ConoHa VPSサポート  機能 機能 ご利用の流れ ご利用の流れ ConoHaデビュー割    ConoHa for Windows  ドメイン ご利用の流れ お申し込み お申し込み 採用情報      Serverサポート ご利用の流れ 導入事例 美雲このはオフィシャ    用語集  ルサイト 導入事例 お申し込み   ワプ活  お申し込み  マイクラゼミ  美雲このは徹底ガイド  会員規約 ｜ ConoHaドメイン登録規約 ｜ ConoHaチャージ利用規約 ｜ ConoHaクーポン利用規約 ｜ 特定商取引法に基づく表記 ｜ 資金決済法に基づく表示 ｜ サービス品質保証制度(SLA) ｜ お問い合わせ ｜ プライバシーポリシー ｜ Cookieポリシー ｜ 会社概要   Copyright © 2023 GMO Internet Group, Inc. All Rights Reserved. https://www.conoha.jp/docs/identity-post_tokens.php 1/1 上記の２つとも何とか取れていますが、パッと見、ちゃんとできているのかよくわからないｗ以下、結果をしっかり読んだ考察です。 [HTML 取込結果]・必要のない MENU ががっつり入っている。そのせいか、本題以外の文章がとても多い。・重要な curl や JSON の情報なし。 [PDF 取込結果]・MENU なし。・curl や JSON あり。 これだけ見ると PDF 一択のようにも見えます。HTML 側の問題回避のアプローチとして以下のような方法がある思います。・MENU など不要な文書をカットするために別のスクリプトを書いてノイズを除去する・ノイズ除去自体を ChatGPT にやってもらう具体的なチューニングまで踏み込めていないのですが、より効率的なデータ抽出のためさらなる検証を継続していこうと思います。 ひとまず元ネタのドキュメントから「文字」データは取れますよねというところができるようになりました。 B. ベクターストアに入れる元ネタドキュメントのチャンク分け 元ネタドキュメントは分割して、 ChatGPT のプロンプトに In-Context として入れやすい小さな塊（=チャンク）にしておく必要があります。この分割は人間が作る、が当然確実なのですが、現実的課題として100だの1000だのというレベルの大量の既存文書を機械的にチャンク化せざるを得ない状況が発生すると思います。 手法としては以下の2点が重要なポイントになります。・元ネタドキュメントの章やページなどの単位でチャンクを分けて、なるべく意味の塊をキープする。・タイトルやキーワードといった文章のメタデータを先頭に付加する。 1回に Embbeding 可能な文章量 ベクターストアに入れるデータは OpenAI の text-embedding-ada-002 でベクトル化を行いますが、こちらは1回に8191トークンが上限です。目安としては5000文字が1回の Embbeding でベクトル化できます。（トークンのカウントは漢字が入ると増えてしまうため TikToken ライブラリで行ったほうが確実です。）ChatGPT への質問プロンプトで送ることができるトークン数と文字数の目安は以下の通りです。gpt-4-0613   : 8,192 tokens （5000文字）gpt-4-32k-0613 : 32,768 tokens （20000文字）gpt-3.5-turbo-0613 : 4,096 tokens （2500文字）gpt-3.5-turbo-16k : 16,384 tokens （10000文字） チャンクサイズとRefine どのぐらいの文章の塊をプロンプトとして ChatGPT に送るべきなのか、という重要な問いを考える上で、私は Refine を前提とした1チャンクの大きさは300文字から1000文字程度のある程度意味のまとまった文章の塊にするといいのではという仮説で進めています。 Refine とは異なるデータを乗せたプロンプトで会話を複数回繰り返し、回答を少しずつ洗練する手法です。Refine に関連する回答生成の手法としては以下のような選択肢があります。・1つの大きなチャンクに全部を入れ込む。・1つの大きなチャンクを複数回送る。（Refine）・複数の小さなチャンクをマージして送る。・複数の小さなチャンクをマージしたものを複数回送る。（Refine）Refine は繰り返し処理のためコスト+処理時間がかかってしまうのがマイナス点なのですが、精度を上げる手法としては一定の効果があると今のところは感じています。最適なチャンクサイズを見つけるには、自分の扱うドキュメントと質問の特性に応じたサイズ検証を設計して、試しながらチューニングしていく他ないと思います。 unstructured でメタデータを入れ込む unstructured で自動的にチャンクを作る方法もあります。こちらは元ネタドキュメントを Elements という文節ごとに区切ってリスト化してくれるので、 1 Element = 1 Chunk として利用する事例もありました。ただ、私は元ネタドキュメントのほうがこの手法と相性が合わなかったようでどうもうまくいきませんでした。先ほどの PDF と HTML の例では文節の Element がいずれもほぼ単語レベルの小さすぎる分割になってしまいました。ここまで小さくなると意味の塊としては用をなしえません。JSON の塊もバラされて1つ1つの項目が別の Elements になってしまったりしたので、このままでは 1 Element = 1 Chunk のような形式にはできないなと。元ネタドキュメントは1ページ全体が小さいので Elements 全体まとめて 1 chunk するのが丁度よいと感じでした。（最大で gpt-3.5-turbo でも 2500 文字、 gpt-4-32k-0613 なら 20000 文字はいけるので、金額をかけてもいいから正確さが欲しいという場合はアリかもしれません。要検証） そうなると登録できる長さを計算し、機械的に一定の長さでループ処理するというのはあながち悪いとも言い切れません。いい感じに2500文字ぐらいのチャンクを作る事例（PDFから情報をとっている）https://qiita.com/sakasegawa/items/16714fa132e874cab069 さらに、メタデータのアイディアがあります。ここでいうメタデータは、タイトルやトピックのキーワードのことです。つまり文章がどんな内容なのかをチャンクの先頭で示し、検索精度を上げようという試みです。 以下で、機械的に文章を分割しながら小見出し的なタイトルをチャンクに入れ込む方法が以下に紹介されています。https://note.com/mahlab/n/n0a8fa0e1d586#6a22a272-b37f-4153-80cc-ca130bb11597こちらはチャンクの先頭にタイトルとサブタイトルに相当する情報を文章に付加しています。このケースでは unstructured でマークダウン（.md）のドキュメントをパースした際に、 title 要素を unstructured の element として取得できる点を活用しています。私の要件のように HTML が元ネタの場合は、ページの title タグや h1 タグをキーワードとして抽出し、それを先頭に記載するという方法が取れると思います。（HTML を unstructured でやってみたら本来 titleでないものがたくさんtitle扱いされてしまい結局使えず）こちらも1つのチャンクには複数のトピックが混ざらないようなもともときれいな内容の分割がされていることがやはり望ましいと言えます。 もう1点、1つ1つのドキュメントの要約を ChatGPT に生成させ、それをチャンクに入れて文章をわかりやすくするというのもアリなのではと思いました。文章が長くはなってしまいますが、より意味の関連度が強められる可能性があります。（検索に効果があるかは未検証） C. ベクターストアに投げる質問プロンプトの最適化 LangChain でも Llamaindex でも質問文は検索前に Embbedings API でベクター化されてから実行されます。ただこの質問文は冗長だったり関係ないものを含むと検索結果もブレが生じるので、質問文自体を形態素解析またはキーワード抽出してからベクター検索をするという方法があります。 形態素解析の場合、ライブラリで処理すれば一発です。 from sudachipy import tokenizer from sudachipy import dictionary # 人間が入力したプロンプト question = "トークン取得APIのパラメータを教えてください。" # 形態素解析モデルの構築 tokenizer_obj = dictionary.Dictionary().create() mode = tokenizer.Tokenizer.SplitMode.C # 形態素解析の実行 tokens = tokenizer_obj.tokenize(question, mode) keywords = [] # keywords for token in tokens: # 名詞だけを抽出して格納 if token.part_of_speech()[0] == "名詞": print(token.surface(), token.part_of_speech()[0]) keywords.append(token.surface()) 結果以下のようにキーワードを抽出できます。 トークン 名詞 取得 名詞 API 名詞 パラメータ 名詞 また、 pke を使えば重要キーワードを機械的に抽出ができます。 !pip install git+https://github.com/boudinfl/pke.git !python -m spacy download ja_core_news_sm import pke import spacy text = "トークン取得APIのURLとパラメータを教えてください。" spacy_model = spacy.load("ja_core_news_sm") extractor = pke.unsupervised.MultipartiteRank() extractor.load_document(input=text, language='ja', normalization=None, spacy_model=spacy_model) extractor.candidate_selection(pos={'NOUN', 'PROPN', 'ADJ', 'NUM'}) extractor.candidate_weighting(threshold=0.76, method='average', alpha=1.1) print(extractor.get_n_best(5)) 最終的にスコアの上位5件を絞り込んでいます。 [('url', 0.39361741945785217), ('トークン 取得 api', 0.30319129027107367), ('パラメータ', 0.30319129027107367)] 「キーワード抽出」はChatGPTに任せるのもありますが、質問するごとに毎回リクエストすることになる点が気になる点です。私の想定するユースケースでは簡単な質問文が使われるので、上記の例だけでも充分ではと思います。 D. 検索結果の精査 検索全般の課題として、以下のような点があると思います。・質問と関係ないドキュメントが検索にヒットしてしまう・ドキュメントが長いと LLM に In-Context Learning で付与できる文字数を超えてしまう こうした課題を LangChain ではどのようにアプローチできるでしょうか。 LangChain の Contextual Compression Retriever を使って部分要約をつくる これは「回答の生成」ではなく「検索結果の精査」のタスクを ChatGPT に担当してもらう方法です。当初の目的であった、ChatGPT に「検索結果から正確な回答を生成させる」ことは実際結構なチューニングが必要でハードルが高いのですが、「検索結果の精査をする」だけに特化すればある程度は機械的に行える可能性があります。 参考にした情報です。https://zenn.dev/laiso/articles/f5e5c616e128a7 ここから検証のため、ベクターストア Faiss をセットアップしていきます。上述の Conoha API ドキュメントから、検索対象となる API の情報を 7 件追加しています。 from langchain.text_splitter import CharacterTextSplitter from langchain.document_loaders import DirectoryLoader from langchain.vectorstores import FAISS def print_docs(docs): print(f"\n{'-' * 10}\n".join([f"Document {i+1}:\n\n" + d.page_content for i, d in enumerate(docs)])) loader = DirectoryLoader('./data_conoha_api', glob="*.txt") docs = loader.load() len(docs) 7つの API ドキュメントがロードされます。 from langchain.embeddings import OpenAIEmbeddings embeddings = OpenAIEmbeddings() ### 初回だけ Embbeding してファイルに保存 ## db = FAISS.from_documents(docs, embeddings) ## db.save_local("faiss_index") # ファイルからFAISSを生成 retriever=FAISS.load_local("faiss_index", embeddings).as_retriever() 素の状態でドキュメントを検索した結果です。 # 「トークン取得APIのパラメータをおしえてください。」のプロンプトを形態素解析した結果のキーワードで検索します # 名詞4つ "トークン 取得 API パラメータ" q=" ".join(keywords) docs = retriever.get_relevant_documents(q)) pretty_print_docs(docs) ベクターストアの検索結果（めちゃくちゃ長いので折りたたまれています） Document 1: Conoha API トークン発行 Identity API v2.0 Description 有効なトークン情報を取得する Request URL identity API v2.0 POST /v2.0/tokens Request Paramters Parameter Value Style Description username ユーザー名 plain ユーザ名 password ユーザーパスワード plain ユーザパスワード tenantId (Optional) Tenant ID plain テナントID Request Json { "auth": { "passwordCredentials": { "username": "ConoHa", "password": "paSSword123456#$%" }, "tenantId": "487727e3921d44e3bfe7ebb337bf085e" } } Normal response codes 200 OK Example ※エンドポイントURLにつきましては、お客様環境によって異なりますので、コントロールパネルにてご確認の上ご利用ください。 REQUEST curl i X POST \ H "Accept: application/json" \ d '{"auth":{"passwordCredentials":{"username":"ConoHa","password":"paSSword123456#$%"},"tenantId":"487727e3921d44e3bfe7ebb337bf085e"}}' \ https://identity.tyo1.conoha.io/v2.0/tokens RESPONSE HTTP/1.1 200 OK Date: Mon, 08 Dec 2014 02:40:56 GMT Server: Apache Content-Length: 4572 Content-Type: application/json { "access": { "token": { "issued_at": "2015 05 19T07:08:21.927295", "expires": "2015 05 20T07:08:21Z", "id": "sample00d88246078f2bexample788f7", "tenant": { "name": "example00000000", "enabled": true, "tyo1_image_size": "550GB", } ], "endpoints_links": [], "type": "mailhosting", "name": "Mail Hosting Service" }, { "endpoints": [ { "region": "tyo1", "publicURL": "https://dns service.tyo1.conoha.io" } ], "endpoints_links": [], "type": "dns", "name": "DNS Service" }, { "endpoints": [ { "region": "tyo1", "publicURL": "https://object storage.tyo1.conoha.io/v1/nc_a4392c0ccba74485abd58ec123eca824" } ], "endpoints_links": [], "type": "object store", "name": "Object Storage Service" }, { "endpoints": [ { "region": "sjc1", "publicURL": "https://identity.sjc1.conoha.io/v2.0" }, { "region": "tyo1", "publicURL": "https://identity.tyo1.conoha.io/v2.0" }, { "region": "sin1", "publicURL": "https://identity.sin1.conoha.io/v2.0" } ], "endpoints_links": [], "type": "identity", "name": "Identity Service" } ], "user": { "username": "example00000000", "roles_links": [], "id": "examplea6963c074d7csample12a886ee", "roles": [ { "name": "SwiftOperator" }, { "name": "_member_" } ], "name": "example00000000" }, "metadata": { "is_admin": 0, "roles": [ "0000000000000000000000000000000e", "11111111111111111111111111111113" ] } } } サービス一覧取得 Database API v1 Description データベースサービスの一覧を取得します。 Request URL Database API v1.0 GET /v1/services Request Paramters Parameter Value Style Type Description X Auth Token header string Userトークン offset(Optional) query int 取得開始位置 Default:0 limit(Optional) query int 取得数 Default:1000 sort_key(Optional) service_name/status/create_date query string ソートキー Default:create_date sort_type(Optional) asc/desc query string ソート順 Default:asc Response Paramters Parameter Value Style Type Description services list service_id plain UUID サービスID service_name plain string サービス名 create_date plain string 作成日時 quota plain int 使用容量上限値（単位GB） total_usage plain float 使用容量合算値（単位GB）、小数点第二位まで表示 status active/suspended/pending/creating/deleting/error plain string ステータス backup enable/disable plain string バックアップ有効フラグ prefix plain string プレフィックス metadata plain dict メタデータ キーと値の辞書オブジェクト total_count plain int 総件数 current_count plain int 現在の取得件数 Request Json This operation does not accept a request body. Normal response codes 200 Success Error response codes 400 Bad Request 401 Access Denied Repeatable Yes Example ※エンドポイントURLにつきましては、お客様環境によって異なりますので、コントロールパネルにてご確認の上ご利用ください。 REQ curl i X GET \ H "Accept: application/json" \ H "Content Type: application/json" \ H "X Auth Token: 39be9f8d53044388b7f2e867eba8b140" \ https://database hosting.tyo1.conoha.io/v1/services RES HTTP/1.1 200 Success Date: Tue, 09 Dec 2014 01:46:58 GMT Server: Apache Content-Length: 1003 Content-Type: application/json { "services" : [ { "service_id": "9d6441f6 c5a0 4dcf a1a9 1a4d724e51fd", "service_name": "dbservice01", "create_date": "2012 11 02T19:56:26Z", "quota": 10, "total_usage": 2.25, "status": "active", "backup": "disable", "prefix" : "02p8y", "metadata" : { "key" : "value" } }, { "service_id": "ff164ba8 42d1 49d3 a597 a98503f6fd45", "service_name": "dbservice02", "create_date": "2012 11 02T19:56:26Z", "quota": 30, "total_usage": 14, "status": "active", "backup": "enable", "prefix" : "8ypg0" "metadata" : { "key" : "value" } } ], "total_count":100, "current_count":10 }----------Document 2: 請求データ一覧取得 Account(Billing) API v1 Description 課金アイテムへの請求データ一覧を取得します。 Request URL billing API v1 GET /v1/{tenant_id}/billing invoices Request Paramters Parameter Value Style Description X Auth Token Userトークン header トークンID tenant_id Tenant ID URI テナントID offset(Optional) 取得開始位置 query Default:0 limit(Optional) 取得数 query Default:1000 Example ※エンドポイントURLにつきましては、お客様環境によって異なりますので、コントロールパネルにてご確認の上ご利用ください。 REQ curl -X GET \ -H "Accept: application/json" \ -H "X-Auth-Token: 35941e7df872405d84e5b026dba8323c" \ https://account.tyo1.conoha.io/v1/487727e3921d44e3bfe7ebb337bf085e/billing-invoices?limit=3 RES HTTP/1.1 200 OK Server: openresty/1.7.10.1 Date: Fri, 08 May 2015 12:52:02 GMT Content-Type: application/json Content-Length: 230 Connection: keep-alive { "billing_invoices": [ { "invoice_id": 00001, "payment_method_type": "Charge", "invoice_date": "2014 08 01T00:00:00", "bill_plas_tax": 500, "due_date": "2014 08 01T00:00:00" }, { "invoice_id": 00002, "payment_method_type": "Charge", "invoice_date": "2014 07 01T00:00:00", "bill_plas_tax": 500, "due_date": "2014 07 01T00:00:00" }, { "invoice_id": 00003, "payment_method_type": "Charge", "invoice_date": "2014 06 01T00:00:00", "bill_plas_tax": 500, "due_date": "2014 06 01T00:00:00" } ] } }----------Document 3: 入金サマリー取得 Account(Billing) API v1 Description 入金のサマリーを取得します。 Request URL billing API v1 GET /v1/{tenant_id}/payment summary Request Paramters Parameter Value Style Description X Auth Token Userトークン header トークンID tenant_id Tenant ID URI テナントID Example ※エンドポイントURLにつきましては、お客様環境によって異なりますので、コントロールパネルにてご確認の上ご利用ください。 REQ curl -i -X GET \ -H "Accept: application/json" \ -H "X-Auth-Token: 35941e7df872405d84e5b026dba8323c" \ https://account.tyo1.conoha.io/v1/487727e3921d44e3bfe7ebb337bf085e/payment-summary RES HTTP/1.1 200 OK Date: Wed, 24 Dec 2014 04:36:31 GMT Server: Apache Content-Length: 141 Content-Type: application/json { "payment_summary": { "total_deposit_amount": 1000 } }----------Document 4: イメージ一覧取得(Glance) Image API v2 Description イメージ一覧を取得 Request URL Image 一覧API v2 GET /v2/images Request Paramters Parameter Value Style Description X-Auth-Token Userトークン header トークンID name (Optional) query イメージ名 visibility (Optional) query 公開(public) または、非公開(private) を指定 member_status (Optional) query イメージメンバーの状態でフィルター owner (Optional) query イメージ所有者(テナントID指定) status (Optional) query イメージの状態 size_min (Optional) query イメージの最小サイズ。単位は bytes size_max (Optional) query イメージの最大サイズ。単位は bytes sort_key (Optional) query ソート対象となる項目。Deault:created_at sort_dir (Optional) query ソートする方向性 default:desc tag (Optional) query イメージタグでフィルター Normal response codes OK (200) Example ※エンドポイントURLにつきましては、お客様環境によって異なりますので、コントロールパネルにてご確認の上ご利用ください。 REQ curl i X GET \ H "Accept: application/json" \ H "X Auth Token: 35941e7df872405d84e5b026dba8323c" \ https://image service.tyo1.conoha.io/v2/images RES HTTP/1.1 200 OK Date: Tue, 09 Dec 2014 10:17:20 GMT Server: Apache Content-Length: 6102 Content-Type: application/json { "images": [ { "status": "active", "name": "testsnap", "tags": [], "container_format": "ovf", "created_at": "2014 12 05T13:16:57Z", "size": 3134390272, "disk_format": "qcow2", "updated_at": "2014 12 05T13:17:14Z", "visibility": "private", "id": "e9a36da8 5c2e 4d8c a7a4 db32e7054d34", "self": "/v2/images/e9a36da8 5c2e 4d8c a7a4 db32e7054d34", "min_disk": 0, "protected": false, "min_ram": 0, "file": "/v2/images/e9a36da8 5c2e 4d8c a7a4 db32e7054d34/file", "checksum": "238c596d2aa5c4c1daa101c4eb3682ff", "owner": "65a85d8e02e7470da8f72ed31effaf4e", "direct_url": "file:///var/lib/glance/images/e9a36da8 5c2e 4d8c a7a4 db32e7054d34", "hw_qemu_guest_agent": "yes", "schema": "/v2/schemas/image" }, { "status": "active", "name": "okvm centos65_ga_fio", "tags": [], "container_format": "ovf", "created_at": "2014 12 05T13:09:24Z", "size": 3135963136, "disk_format": "qcow2", "updated_at": "2014 12 05T13:09:41Z", "visibility": "private", "id": "7e8ef227 9000 46f2 82b4 c7d68f1bcf96", "self": "/v2/images/7e8ef227 9000 46f2 82b4 c7d68f1bcf96", "min_disk": 0, "protected": false, "min_ram": 0, "file": "/v2/images/7e8ef227 9000 46f2 82b4 c7d68f1bcf96/file", "checksum": "5331449d33377d47459628542f542d4d", "owner": "65a85d8e02e7470da8f72ed31effaf4e", "direct_url": "file:///var/lib/glance/images/7e8ef227 9000 46f2 82b4 c7d68f1bcf96", "hw_qemu_guest_agent": "yes", "schema": "/v2/schemas/image" }, { "status": "active", "name": "okvm centos65", "tags": [], "container_format": "ovf", "created_at": "2014 12 05T12:33:00Z", "size": 2967273472, "disk_format": "qcow2", "updated_at": "2014 12 05T12:33:18Z", "visibility": "private", "self": "/v2/images/7b85762c 23d0 4ed0 805b b5a0604049a2", "min_disk": 0, "protected": false, "id": "7b85762c 23d0 4ed0 805b b5a0604049a2", "file": "/v2/images/7b85762c 23d0 4ed0 805b b5a0604049a2/file", "checksum": "765f4a4670240bcd1e7f40fe5e655c90", "owner": "4a9f0a43587e46258d6b0feb45b58b31", "direct_url": "file:///var/lib/glance/images/7b85762c 23d0 4ed0 805b b5a0604049a2", "min_ram": 0, "schema": "/v2/schemas/image" }, { "status": "active", "name": "okvm centos65_ga", "tags": [], "container_format": "ovf", "created_at": "2014 12 05T12:32:10Z", "size": 2967273472, "disk_format": "qcow2", "updated_at": "2014 12 05T12:32:26Z", "visibility": "public", "id": "0481cc6f 5cee 474c bdf3 b46c793a94ec", "self": "/v2/images/0481cc6f 5cee 474c bdf3 b46c793a94ec", "min_disk": 0, "protected": false, "min_ram": 0, "file": "/v2/images/0481cc6f 5cee 474c bdf3 b46c793a94ec/file", "checksum": "5ada4a66c2598d39fb6aacc6731aeae4", "owner": "4a9f0a43587e46258d6b0feb45b58b31", "direct_url": "file:///var/lib/glance/images/0481cc6f 5cee 474c bdf3 b46c793a94ec", "hw_qemu_guest_agent": "yes", "schema": "/v2/schemas/image" }, { "status": "active", "name": "okvm centos65", "tags": [], "container_format": "ovf", "created_at": "2014 12 03T08:22:44Z", "size": 2967273472, "disk_format": "qcow2", "updated_at": "2014 12 03T08:23:02Z", "visibility": "public", "self": "/v2/images/765acb4f e4df 4f9f a37c e062df376504", "protected": false, "id": "765acb4f e4df 4f9f a37c e062df376504", "file": "/v2/images/765acb4f e4df 4f9f a37c e062df376504/file", "checksum": "765f4a4670240bcd1e7f40fe5e655c90", "min_disk": 0, "direct_url": "file:///var/lib/glance/images/765acb4f e4df 4f9f a37c e062df376504", "min_ram": 0, "schema": "/v2/schemas/image" }, { "status": "active", "name": "cirros 0.3.3 x86_64", "tags": [], "container_format": "bare", "created_at": "2014 12 03T07:48:41Z", "size": 13200896, "disk_format": "qcow2", "updated_at": "2014 12 03T07:48:42Z", "visibility": "public", "self": "/v2/images/3cab9d0f 29b1 45e3 b5fd 76e8d746b289", "protected": false, "id": "3cab9d0f 29b1 45e3 b5fd 76e8d746b289", "file": "/v2/images/3cab9d0f 29b1 45e3 b5fd 76e8d746b289/file", "checksum": "133eae9fb1c98f45894a4e60d8736619", "min_disk": 0, "direct_url": "file:///var/lib/glance/images/3cab9d0f 29b1 45e3 b5fd 76e8d746b289", "min_ram": 0, "schema": "/v2/schemas/image" }, { "status": "active", "name": "cirros 0.3.3 x86_64", "tags": [], "container_format": "bare", "created_at": "2014 12 03T07:48:38Z", "size": 13200896, "disk_format": "qcow2", "updated_at": "2014 12 03T07:48:39Z", "visibility": "public", "self": "/v2/images/fd2cbdb5 b4dd 4afe 8409 fb2998ca50ef", "protected": false, "id": "fd2cbdb5 b4dd 4afe 8409 fb2998ca50ef", "file": "/v2/images/fd2cbdb5 b4dd 4afe 8409 fb2998ca50ef/file", "checksum": "133eae9fb1c98f45894a4e60d8736619", "min_disk": 0, "direct_url": "file:///var/lib/glance/images/fd2cbdb5 b4dd 4afe 8409 fb2998ca50ef", "min_ram": 0, "schema": "/v2/schemas/image" }, { "status": "active", "name": "cirros 0.3.3 x86_64", "tags": [], "container_format": "bare", "created_at": "2014 12 03T07:42:58Z", "size": 13200896, "disk_format": "qcow2", "updated_at": "2014 12 03T07:42:59Z", "visibility": "public", "self": "/v2/images/a6f3a56f 0e21 4dfc b267 9df611034a5d", "protected": false, "id": "a6f3a56f 0e21 4dfc b267 9df611034a5d", "file": "/v2/images/a6f3a56f 0e21 4dfc b267 9df611034a5d/file", "checksum": "133eae9fb1c98f45894a4e60d8736619", "min_disk": 0, "direct_url": "file:///var/lib/glance/images/a6f3a56f 0e21 4dfc b267 9df611034a5d", "min_ram": 0, "schema": "/v2/schemas/image" }, { "status": "active", "name": "cirros 0.3.3 x86_64", "tags": [], "container_format": "bare", "created_at": "2014 12 03T07:41:52Z", "size": 13200896, "disk_format": "qcow 以下は ContextualCompressionRetriever で検索結果を ChatGPT で要約してから表示しています。（そのため検索するたびにリクエストはガンガン発生します。） from langchain.chat_models import ChatOpenAI from langchain.retrievers import ContextualCompressionRetriever from langchain.retrievers.document_compressors import LLMChainExtractor from langchain.retrievers.document_compressors import EmbeddingsFilter from langchain.document_transformers import EmbeddingsRedundantFilter from langchain.retrievers.document_compressors import DocumentCompressorPipeline from langchain.text_splitter import CharacterTextSplitter llm = ChatOpenAI(temperature=0, verbose=True) compressor = LLMChainExtractor.from_llm(llm) compression_retriever = ContextualCompressionRetriever(base_compressor=compressor, base_retriever=retriever, verbose=True ) compressed_docs = compression_retriever.get_relevant_documents(q) print_docs(compressed_docs) 要約版のベクターストアのドキュメント検索結果。取得してからChatGPTが要約しています。最初の素のベクター検索結果に比べてだいぶ簡素です。結構情報が抜けているとも言えます。 Document 1: トークン発行 有効なトークン情報を取得する POST /v2.0/tokens { "auth": { "passwordCredentials": { "username": "ConoHa", "password": "paSSword123456#$%" }, "tenantId": "487727e3921d44e3bfe7ebb337bf085e" } } 200 OK サービス一覧取得 GET /v1/services X-Auth-Token: 39be9f8d53044388b7f2e867eba8b140 { "services" : [ { "service_id": "9d6441f6c5a04dcfa1a91a4d724e51fd", "service_name": "dbservice01", "create_date": "2012-11-02T19:56:26Z", "quota": 10, "total_usage": 2.25, "status": "active", "backup": "disable", "prefix" : "02p8y", "metadata" : { "key" : "value" } }, { "service_id": "ff164ba842d149d3a597a98503f6fd45", "service_name": "dbservice02", "create_date": "2012-11-02T19:56:26Z", "quota": 30, "total_usage": 14, "status": "active", "backup": "enable", "prefix" : "8ypg0" "metadata" : { "key" : "value" } } ], "total_count":100, "current_count":10 } ---------- Document 2: "Userトークン" ---------- Document 3: 入金のサマリーを取得します。 トークンID ---------- Document 4: GET /v2/images Request Paramters Parameter Value Style Description X-Auth-Token Userトークン header トークンID  最後に ContextualCompressionRetriever とは少し違うアプローチで使える検索結果のフィルター処理を紹介します。DocumentCompressorPipeline で複数の処理を実行し、検索結果に処理を入れて減らしていきます。実はこれが一番役に立つかも。 from langchain.chat_models import ChatOpenAI from langchain.text_splitter import CharacterTextSplitter from langchain.retrievers.document_compressors import EmbeddingsFilter from langchain.document_transformers import EmbeddingsRedundantFilter from langchain.retrievers.document_compressors import DocumentCompressorPipeline # この例ではまずはじめに普通にベクターストアを検索する docs = retriever.get_relevant_documents(question) ### フィルター処理の設定 # 1 検索結果ドキュメントをさらに分割。小分けにして増やす。 # 1つのチャンクが長い場合、重要なところにフォーカスを上げる splitter = CharacterTextSplitter(chunk_size=500, chunk_overlap=0, separator="\n") # 2 質問プロンプト文と類似しすぎている検索結果を排除する。 redundant_filter = EmbeddingsRedundantFilter(embeddings=embeddings) # 3 小さくしたドキュメントのEmbeddingsを改めて作成し、質問プロンプト文との類似性を比較。しきい値以下を排除 relevant_filter = EmbeddingsFilter(embeddings=embeddings, similarity_threshold=0.80) # 各フィルターをDocumentCompressorPipelineでつないで、検索結果を減らす処理を行う pipeline_compressor = DocumentCompressorPipeline( transformers=[splitter, redundant_filter, relevant_filter] ) filterd_docs = pipeline_compressor.compress_documents(docs, question) print_docs(filterd_docs)  結果、いいかんじになっています。 Document 1: Conoha API トークン発行 Identity API v2.0 Description 有効なトークン情報を取得する Request URL identity API v2.0 POST /v2.0/tokens Request Paramters Parameter Value Style Description username ユーザー名 plain ユーザ名 password ユーザーパスワード plain ユーザパスワード tenantId (Optional) Tenant ID plain テナントID Request Json { "auth": { "passwordCredentials": { "username": "ConoHa", "password": "paSSword123456#$%" }, "tenantId": "487727e3921d44e3bfe7ebb337bf085e" } } Normal response codes 200 OK Example ---------- Document 2: ※エンドポイントURLにつきましては、お客様環境によって異なりますので、コントロールパネルにてご確認の上ご利用ください。 REQUEST curl i X POST \ H "Accept: application/json" \ d '{"auth":{"passwordCredentials":{"username":"ConoHa","password":"paSSword123456#$%"},"tenantId":"487727e3921d44e3bfe7ebb337bf085e"}}' \ https://identity.tyo1.conoha.io/v2.0/tokens RESPONSE HTTP/1.1 200 OK Date: Mon, 08 Dec 2014 02:40:56 GMT Server: Apache Content-Length: 4572 Content-Type: application/json { "access": { "token": { "issued_at": "2015 05 19T07:08:21.927295", ---------- Document 3: header string Userトークン offset(Optional) ... （20まで続く）  refine の中でChatGPT回答が複数得られるので回答同士の類似度を判定する 上記の例では、関係のない文書も含めて要約したりEmbbedingしたりするのでOpenAI API実行回数がだいぶ多いです。別のアプローチとして、LangChainやLlamaindexで用いられる refine の処理の途中で、回答同士の変化度の判定を行います。例えば、回答1から回答2に変更があった場合に回答2に価値があるとみなすことができます。類似度・関連度を活用するのとは逆のアプローチになると思います。 そもそも人間でも精査が難しいということもあると思っていて、全部の検索結果を表示してしまうのも別にいいのではと思ったりします。 E. ベクターストアの選定 ベクトルDB、ベクター検索エンジンなど様々な呼ばれ方をしていますが、類似した文書を高速に検索することができます。 結論として私はまだ選定の最適解に到達していません。なのでここはおまけです。 Githubのスター数でランキングを作っているサイトがありました。こちらは非常に参考になります。https://byby.dev/vector-databases Faiss がスター数でも知名度でも一番です。 ユースケース別に考えると、以下のような視点があります。 １）既存のDB運用があるのでそこに混ぜていきたいpgvector ２）マネージドで他のシステムに影響なく独立して運用したい＋大きなデータセットになった場合のスケーラビリティがあるElasticSearchmilvuspinecone こちらに出ていないものとして最近の注目株は Chroma があります。https://www.trychroma.com/ 個人的に Chroma の強みと感じているのは metadata を付与できる部分です。こちらは検索フィルタとして利用できるので、検索精度を上げることができます。公式の例では { status: [read/unread] } というステータス値を管理させています。https://github.com/chroma-core/chroma/blob/main/examples/basic_functionality/where_filtering.ipynbドキュメントの種類が広範囲にわたる場合はこの metadata にカテゴリ名などタグ付けをしていくことで検索精度を改善できると思います。LangChain, LlamaIndex と連携できる API があり、実装上は簡単にいける点も魅力的です。 まとめ A. ベクターストアに入れる元ネタドキュメントの抽出⇒ unstructured が使えるかも B. ベクターストアに入れる元ネタドキュメントのチャンク分け⇒ タイトル。キーワードをメタデータで付加 C. ベクターストアに投げる質問プロンプトの最適化⇒ 形態素またはキーワード抽出でプロンプトを精査 D. ベクターストア検索結果の精査⇒ ContextualCompressionRetrieverによる検索結果要約とDocumentCompressorPipelineによる検索結果精査がよさげ E. （おまけ）ベクターストアの選定⇒ 1位はFaiss。マネージドも多々あり。Chromaがこれから来るかも。 まだ全体としては不十分な点が多々ありますが、「検索結果が質問に沿ったものか精査させる」タスクをChatGPTに担当してもらうことが私の業務課題には適しているのでは。。という気づきがありました。これは大いなる前進です。元の目的は「検索結果の精度を上げてChatGPTが正確な回答ができるようにする」という点がありましたが、そこにこだわるのではなく、検索精度の向上自体をChatGPTに手伝ってもらうことが業務効率化につながる道が見えてきたので、この点をさらに研ぎ澄ましていこうと思います。 現在公開可能な情報は以上です。 最後に宣伝 次世代システム研究室では、最新のテクノロジーを調査・検証しながらインターネットのいろんなアプリケーションの開発を行うアーキテクトを募集しています。募集職種一覧 からご応募をお待ちしています。

GMOインターネットグループでは年に一度、最も活躍した仲間を讃える社内表彰「GMOアワード」を開催しています。今年のテーマは「世界中の仲間とつながり互いを尊敬するGMO AWARDS 2023 」。ノミネートされたパートナー（社員）のプレゼンテーションをもとに全社で投票が行われて、全6賞・23部門の受賞者・チームが決まります。 発表は6月に新設されたばかりのハイブリッドイベントスペース「GMO GLOBAL STUDIO」からLIVE配信され大盛況となりました。今回はそんな「GMOアワード2023」についてノミネートから発表までの模様をお届けします。 GMOアワードについて 今年で15回目を迎える「GMOアワード」は、全世界で働くグループパートナー約7800人（※2023年2月末時点）を対象に、その年に活躍した会社・部門・チーム・個人を表彰するビッグイベントです。 今年のテーマは「世界中の仲間とつながり互いを尊敬するGMO AWARDS 2023 」。 「愛・尊敬・誇り」をメインキーワードにノミネートされたパートナーの皆さんは、プレゼンテーションで、働く仲間への感謝や、仕事で得られた成果について伝えました。 GMOインターネットグループには、国内7000人以上のパートナーがおり、その内49.93%（※2023年6月末時点）がエンジニア・クリエイターとして働いています。 「GMOアワード」では、最も活躍した国内のパートナーに与えられる「最優秀個人賞」をはじめ、エンジニア・クリエイターを称える賞も多数設けられています。 各賞について 「GMOアワード2023」各賞についてご紹介します。 個人の部 新人賞グループで最も活躍した新卒パートナー（対象：2022年4月1日に入社）に授与創る人部門（エンジニア）創る人部門（クリエイター・ディレクター） 守る人部門（サポート・管理・アシスタント） 売る人部門（営業・マーケティング） キャリア新人賞グループで、最も活躍したキャリア採用で入社したパートナー（対象：2021年7月1日～2022年6月30日に入社）に授与創る人部門（エンジニア・クリエイター・ディレクター） 守る人部門（サポート・管理・アシスタント） 売る人部門（営業・マーケティング） 個人賞グループで、2022年度、最も活躍した国内勤務パートナーに授与エンジニア部門 クリエイター部門 プランニング部門サポート部門コーポレート部門セールス部門国内エリア部門 個人・団体の部 海外賞グループで、海外20ヶ国、59拠点で活躍するパートナーにそれぞれ授与創る人部門（エンジニア・クリエイター・ディレクター）守る人部門（サポート・管理・アシスタント）売る人部門（営業・マーケティング）グローバルプロジェクト部門 団体の部 セグメント賞グループで最も活躍したプロジェクトをセグメント別に称えます インフラ部門EC決済部門メディア部門金融VC暗号資産部門さらに各部門1位の中でも最も素晴らしい成果を上げたチームには「最優秀セグメント賞」が贈られました。 「GMOアワード2023」受賞までの道のり GMOアワードの獲得したパートナーは、どのような道を歩んできたのか。その軌跡をお伝えします。 ノミネート決定 2022年4月1日から2023年3月31日までの実績をもとに、GMOインターネットグループ全社より、各賞のノミネートパートナーが選出されました。 「Road to GMO AWARDS 2023」でプレゼンテーション ノミネートされたパートナーは4月末、GMOインターネットグループの全パートナーに向けて60秒間でPRする「Road to GMO AWARDS 2023」を行いました。 「Road to GMO AWARDS 2023」では、普段、同じ部門で働く仲間となるパートナーが応援団として発表を盛り上げました。 GMOインターネットグループ株式会社　木村まりあさん（キャリア新人賞 守る人）の発表 60秒という限られた時間の中で、いかに想いを伝えられるか。ノミネートされたパートナーは、この発表の場でのプレゼンテーション力も問われます。 仕事やプロジェクト・働く仲間への感謝を言葉で伝える方、これまで歩んできた人生を紹介する方、成し遂げた実績を堂々と発表する方など、それぞれ渾身の力を込めたプレゼンが行われました。 投票 「Road to GMO AWARDS 2023」でのプレゼンや資料をもとに、4～6月に全パートナーが投票を行い、各賞それぞれ、最もふさわしい受賞者が決まりました。 「GMOアワード 2023」発表 全パートナーが行った投票結果は、6月20日に行われた「GMOアワード 2023」で発表されました。 「GMOアワード 2023」は、6月に新設されたリアルとオンラインでのハイブリッドイベントスペース「GMO GLOBAL STUDIO」にて、LIVE配信で実施され、最新のVFX映像技術を駆使した圧巻のセレモニーとなりました。 ハイブリッドイベントスペース「GMO GLOBAL STUDIO」 授賞式では「Road to GMO AWARDS 2023」同様、普段、同じ部門で働く仲間のパートナーが見守るなか、各賞、得票点数がリアルタイムに発表されて受賞者が決まります。 受賞が決まった瞬間、大きな歓声が広がり、受賞者の周りはお祭り騒ぎに。その熱狂はオンライン画面からも伝わってきました。残念ながら受賞を逃してしまったパートナーも、一丸となって、みんなで健闘を讃え合う。そんな一体感のある授賞式となりました。 「キャリア新人賞 守る人」最優秀賞（1位）受賞の瞬間！ （GMOインターネットグループ 木村まりあさん） エンジニア部門 受賞者コメント 開発者向けの技術情報やイベント情報をお届けしている「GMO Developers」。 今回は「新人賞（創る人-エンジニア部門）」で最優秀賞(1位) を受賞したGMOアドマーケティングの天河 京民さん、「個人賞－エンジニア部門」で最優秀賞(1位) を受賞したGMOペイメントゲートウェイの羽鳥 樹さん、お二人のコメントをお伝えします。 「新人賞（創る人-エンジニア部門）」最優秀賞(1位) 受賞天河 京民さん　GMOアドマーケティング　開発本部　開発部 天河さん：2年ほど前の最終面接の後、GMOアドマーケティングの社内を見学させていただいた際、エンジニアで過去に受賞した上長の方がおられ、でっかい賞金ボードが飾られていました。それを見た時から僕はGMOアワードに憧れていました。入社前から頭の中にGMOアワードがいたんです。そして入社してから一年間、アワードを意識して多くの人に伝わりやすい実績を積み上げていきました。その過程で本当にとても多くの人にお世話になり、仕事は自分の力ではなく周りの支え、「愛」があってこそ、パフォーマンスと成果が出せるものだと強く実感しました。 その方々から受けた「愛」に応えたいという一心で「これで負けたら仕方ない」と思えるくらい、できることは全て行ってこのアワードの舞台に立ちました。なので、こうして受賞することができたのはとても感慨深いものがあります。特に周りの方が喜んでいる様子を見て、本当に頑張って来た甲斐があったと思いました。今回、新人賞を受賞すると同時に、自分の中で「GMOインターネットグループ最優秀新人賞を受賞したエンジニアである」という大きな責任感も湧いて来ました。この賞に恥じぬよう、名実ともにGMOインターネットグループの影響力をさらに高めていくエンジニアになっていきますので、ご期待ください！ ---天河さんは、別記事でインタビューにもお応えいただきました。どうぞご覧ください。 「【GMOアワード 2023】最優秀新人賞（創る人-エンジニア部門）インタビュー」 https://developers.gmo.jp/37233/ 「個人賞－エンジニア部門」最優秀賞(1位) 受賞 羽鳥 樹 さん GMOペイメントゲートウェイ システム本部 IT戦略ビジネス統括部 プロセシング部 羽鳥さん：この度は、大変名誉ある賞に選んで頂き光栄の至りです。心から感謝申し上げます。普段業務でお世話になっている皆様をはじめ、日々陰ながらご尽力頂いている皆様のおかげで受賞できたものと考えております。重ねて感謝申し上げます。ノミネートの理由は２つあり、ひとつは社内への情報発信をご評価頂きました。この点については、発信に対するシステム本部の皆様からの反応が嬉しく、励みになっていたためマイペースに続けていただけなので、それをこれ程ご評価頂けるとは夢にも思いませんでした。今後は期待に応えるという意識は持ちつつも、肩肘を張らず引き続きマイペースに発信を続けていきたいと思います。 もうひとつは、PG初のクレジットイシュイングシステム導入プロジェクトに対する貢献をご評価頂きました。クレジットイシュイングシステムでは今までのデビット・プリペイドのシステムではなかった、債権やリスクの管理、途上与信といった難しい業務と向き合う必要があります。これらを、外部のパッケージシステムを導入することで社内にノウハウを取り入れますが、業務の複雑さはもとより、既に存在する巨大なシステムを解析・理解する必要があるため、私自身のライフワークになる予感がしております。大きな責任を背負っているという意識の下、業務に邁進していく所存です。 この賞に恥じないビジネスパーソンとなれるよう、今後も成長していきますので、皆様ご支援のほど何卒宜しくお願い致します。この度は本当に有難うございました。-- このようにエンジニア・クリエイターも大活躍した「GMOアワード2023」。さまざまな職種で、グループパートナー一人ひとりの活躍が評価される場として、有意義な機会となりました。 さいごに​ GMOインターネットグループは、”すべての人にインターネット”をコーポレートステートメントに掲げ、インフラ、広告、金融、暗号資産事業など幅広い業種で事業を展開しています。これらの事業すべてを支えるパートナーの存在があります。 「愛・尊敬・誇り」というメインキーワードで行われた「GMOアワード2023」は、共に働く仲間に対する「愛」を示して、互いの成果を「尊敬」し合い、自分の仕事に「誇り」を持つ。そんな場面がいくつも見られました。 お互いを尊敬して、グループ内で連帯感を高め合う。グループにとってなくてはならないイベントとなっています。来年はどのような感動を届けてくれるのか。ぜひご期待ください。

GMOインターネットグループでは、一年に一度、その年に活躍した会社・部門・チーム・個人を表彰する社内イベント「GMOアワード」を開催しています。「GMOアワード2023」では、グループパートナー（社員）約7,000人の中から、グループで最も活躍したパートナーに授与される「最優秀個人賞」をはじめ、計6賞・23部門の名誉ある賞が投票によって選出されました。2022年度に入社したグループ10社・130名の新卒パートナーから、最も活躍した新卒パートナーに贈られる「新人賞（創る人-エンジニア部門）」で最優秀賞(1位)を受賞したのがGMOアドマーケティング株式会社の天河 京民さんです。今回は、受賞までの経緯や、今後の目標について、お話しを伺いました。 GMOアワードについてはこちら https://developers.gmo.jp/38399/ GMOアワード2023 最優秀新人賞（創る人-エンジニア部門）受賞 天河 京民（てんかわ けい）GMOアドマーケティング株式会社　開発本部　開発部2022年4月、GMOアドマーケティング株式会社に新卒入社。GMO AD Partners AWARDS 2023 新人賞 創る人 エンジニア部門を受賞。Lightning Talk大会 2023年上期 金賞を受賞。GMOアワード2023 最優秀新人賞（創る人-エンジニア部門）を受賞。天河さんはGMOアドマーケティングが運営するレコメンドウィジェット「TAXEL」のエンジニアとして、管理画面の開発や広告デザインの改修を行っています。昨年は、開発案件とプロダクト運用の両面で大きくチームに貢献し、さらにGMOアドパートナーズのテックブログ「GMO AD Partners TECH BLOG by GMO」での執筆も積極的に行っており、これらの実績が受賞に大きく寄与しました。 ―――あらためて受賞おめでとうございます！今、振り返ってみていかがですか。 やっぱり嬉しかったですね。GMOアドマーケティングで最優秀新人賞（創る人-エンジニア部門）は、僕が2人目なんですよね。2016年入社の先輩である石丸智輝さん（開発部 開発6グループ）が、過去に受賞されています。 2年前の最終面接でオフィスを見学させていただき、石丸さんの賞金ボードが飾られているのを見ました。そこで先輩方からGMOアワードについて教えて頂いて、「そういう賞みたいなのがあるんだな」と何となく意識する程度でした。 入社2カ月ぐらいは日々の業務をこなすので精一杯でしたが、仕事するなかで実績が数字にも現れてきて、「この実績があれば、プレゼンさえちゃんとしていたら獲れるかもしれない」と思うようになりました。今年の3月にはGMOアドパートナーズ社内での社内表彰「GMO AD Partners AWARDS 2023」で新卒の中から新人賞 創る人 エンジニア部門を頂くことができました。 こうした積み重ねが今回のGMOアワードでの自信にもつながり、受賞できたと思っています。 ―――パートナー（社員）の皆さんから支持を得られたポイントは、どこにありましたか？ 社内の先輩方にも手助けいただき、誰よりも目立つことができたからだと思います。 GMOアワード2022で個人賞を受賞したGMO NIKKO株式会社の吉田一貴さん（GMO NIKKO プランニング本部 マーケティングプランニング部）が、「GMOアワード攻略セミナー」なるものを開いてくれました。そこで投票者の目を引くためのポイントを教えていただきました。 例えば、ノミネート者を紹介するウェブサイトに掲載するプロフィール写真について「印象に残るもので攻めろ！」とアドバイスをもらったので、目立つデザインで挑みました。 また、GMOインターネットグループで毎週金曜日開催されている「BarTime」（そこではお酒や料理を楽しみながらグループパートナー同士、気軽にコミュニケーションを取れます）で行われた投票促進イベントでは、先輩方が率先してグループのパートナーに投票を呼びかけてくれました。 ――――さすが広告の会社ならではですね。4月末には、ノミネート者がGMOインターネットグループのパートナーに向けて、60秒間でPRする「Road to GMO AWARDS 2023」が行われました。天河さんは、実績を３つのポイントに絞って伝えるプレゼンが、分かりやすくて印象的でした。これまでも自身をアピールするのは得意だったんですか？ いや、入社するまで得意ではなかったです。 なぜプレゼンに自信があるようにみえるかというと、回数をこなしてきたからです。「GMO AD Partners AWARDS 2023」での2回のプレゼンと、GMOアドマーケティングで半期に1度おこなわれるテックイノベーション「Lightning Talk大会」など、プレゼンをする機会が多くあり、そこで経験を積めました。 発表内容は、普段の僕の仕事を知っている上司はもちろん、僕の仕事についてあまり知らない社外の友達にも聞いてもらい、どちらにも反応がいい内容を選びました。 あとはシンプルに練習。あの１分間の発表だけで300回は練習しました。身体で覚えるぐらいやって、初めてやっと自分の言いたいことが思うように伝えられましたね。 プレゼンでは、エンジニア用語を１つも使っていません。聞いている人は専門用語を言われた瞬間に「あー、なんか言っているな」と、気持ちが離れてしまうと思ったからです。エンジニアの僕でも「アーキテクチャ」や「Vue.js」などの専門用語を言われると「ウッ」ってなりますから。 ―――「TAXEL」の開発現場でも、わかりやすさは意識していますか？ そうですね。「TAXEL」の開発では、事業部や営業部はもちろん、導入いただいているメディアの皆様がより使いやすくなるような新規機能の開発や不具合修正、お問い合わせ対応などを行っています。 システムの知識がない方でも直感的に使っていただけるプロダクトを目指していることからも、わかりやすく物事を伝える、現わすことは大切にしています。 ―――どういった時、お客様から喜んでいただけますか？ 素早い対応をした時に喜んでもらえることが多いです。僕も普段から迅速な対応を心がけているので、それに対する感謝があると僕も嬉しいですね。また、自らユーザーさんのことを考えた改修を行なって「便利になった」という声を頂いた時は嬉しいですね。 ――――普段、どのような仕事の仕方を心がけていますか。 「即レス」ですね。実際に隣にいるのと変わらないスピード感でコミュニケーションすることを意識しています。 僕自身がせっかちというのもあると思いますが、事業部から頼まれる事というのは、大抵の場合、はやく対応して欲しい事だと思うんですよね。 「サイトへの導入を同意いただいたので、システムに登録してください」という連絡を受け取った際、5分以内に登録し終えて「登録しました！」と言うと「早すぎ！」と驚かれたりします（笑） スピード感を意識した動き方として、最初から100点を目指さず、少し雑でもいいから成果物を早く出すことを大切にしています。そうした方が、依頼者と大きな齟齬が生まれず、余計な手戻りが少なくなると感じています。 ―――新卒が大切にすべきことはありますか。 一つ目「挨拶」、二つ目「即レス」、三つ目は…とりあえず動き続けるという意味の「多動」です。 順番は前後するのですが、「多動」から説明します。 GMOアワードなどの舞台で自信持って発表できる事があるかどうかは、結局は日々の積み重ねだと思っています。開発タスク数と運用タスク数も普段の業務をきちんと行なっていると、結果的に部署内で「一番」タスクを実施していたと言う「数字」で表せるわけですよね。 技術ブログでの発信も積極的に行っていますが、執筆本数というのも積み重ねると数字で表せる成果になります。このようにシンプルにたくさん行動するというのは最終的に自分の評価につながってくると感じます。 GMOアドマーケティングが、そうした自由に「多動できる」環境だということも、恵まれていると思っています。 「Lightning Talk大会」では、グループパートナーが気軽に利用できるシナジーカフェ 「GMO Yours・フクラス」で人気の「デットクスウォーター」が、社内ポータルの監視カメラの画像から“あるかどうか”を判定するため、5000枚以上写真を撮影したり、「GMO Yours・フクラス」で働くパートナーにも2時間インタビューするなどしました。 こうして作成したデトックスウォーターの存在を判定するAIモデルの発表は、2023年上半期LT大会で金賞を頂きました。表彰式で取締役から「才能の無駄遣い」と言われましたが（笑） ただこうした成果も、常に動いていることで得たことだと思います。動いていると面白い人とも知り合うことができるなど、新しいチャンスに出会えることを実感しています。 でも僕は多動よりも大切だと思っているのは一つ目の「挨拶」だと思っています。 ――――挨拶が一番大事ですか！？ 「自分からする挨拶」ですね。会社では、自分から挨拶することを意識しています。 GMOアドマーケティングに入社するまで僕は内気な性格でした。でも入社してから社内の人に自ら積極的に挨拶をすることで、人と臆せず関われるようになりました。 挨拶することを習慣化していないと、お客様がご来社された際に対応できなかったりします。そうすると会社のイメージにも影響しますし、自分自身も損します。 また、AIが発展してきて技術の役割をAIにある程度任せられる時代になった今だからこそ、技術だけでなく、このような礼儀や人格的なところをもっと大事にしていく必要があると思います。 なので皆さん、ぜひとも自ら進んで挨拶してください！ ―――新卒エンジニアに向けたアドバイスはありますか？ これは自分自身も心得ていることですが、技術力は前提として大事だけど、それだけじゃなくて周りとのコミュニケーションや、人間力みたいなところも高めて欲しいです。 自分の持っている知識やプログラミングに自信を持ちすぎてしまうと、技術ばかりに目が行ってしまい、相手の本当に求めている事に気づくことができない事態に陥ってしまうこともあると思います。 事業というのは、自分がやりたいことよりも相手がやりたいことを実現することが大事だと思うので、そういう意味でもコミュニケーション、とくに相手の話をきちんと聞くという姿勢は大切にして欲しいですね。 ――――今後の目標を教えてください。 まず自分が従事している業務範囲を完璧にしたいです。「TAXEL」に関しては誰よりも一番詳しいレベルになること。これは直近で、必ず成し遂げたい目標ですね。 来年（2024年）は入社3年目を迎えますが、自分の発案によって会社の売り上げや業務効率化に貢献していきたいです。 そして「GMOインターネットグループのエンジニアといえば天河」といった感じで社内外に知られるエンジニアになりたいです。 GMOインターネットグループ株式会社の成瀬さん（GMOアワード2021個人賞）はGMOデベロッパーエキスパートとしても活躍しており、社内外でも広く知られているエンジニアだと思います。 成瀬さんのように、テックカンファレンスにも登壇できるように、技術力を向上させるのはもちろん、発信力も高めていきたいです。 貴重なお話しをありがとうございました。天河さんの今後の活躍に、ぜひご期待ください！