技術情報 の記事一覧

こんにちは、GMOインターネットグループ株式会社 ネットワークソリューションチームの梅崎です今回は主にサーバー管理者/アプリ開発者向けに「ネットワークが繋がらない、通信ができない」となったときの・ クライアント/サーバー側で可能なトラブルシュート方法・ ネットワーク管理者へ調査依頼を出す際に我々が欲しい情報をまとめてみました今回はそのエラー内容特定編です 注意事項 基本的には上からなぞっていけば大丈夫な形にはしていますがWindows機などはコマンドが違うことが多くコメントでやりたいことを記載しているので同様の情報を取得できるものを探していただければと思います あと、IPv6の調査はあまりやったことは無いですが基本的にはトラブルシュート方法は変わらずコマンドにIPv6用のオプションをつければ大丈夫だと思います どんなエラーなのかを特定 この章では最低限、通信の問題なのかクライアント/サーバーのアプリケーション的なエラー、設定の不備なのかを切り分けする方法を記載しています ブラウザ等で404や403といった4xxエラーが表示される クライアントとサーバーとの通信は問題ないです「URLが誤っている」かサーバーで「ファイルが存在しない」、「アクセスを許可していない」等が原因のため URLの再確認とWebサーバー側の設定の確認が必要です ブラウザ等で500や504といった5xxエラーが表示される クライアントとサーバーとの通信は問題ないですサーバー側のエラーやバックエンドが落ちているなどが原因の可能性が高いです サーバー、バックエンド側のログの確認が必要です ※サーバーとバックエンドの「通信に問題がある場合(作成中)」を参照してください 名前解決に失敗する 「URLが誤っている」か「DNSサーバーの設定が無い」「リゾルバの設定がされていない/間違えている」かなと思いますURLの再確認とDNSサーバー側の設定の確認、クライアント側のリゾルバの設定の確認が必要です タイムアウトエラーが表示される(Webに限らず) クライアントとサーバーとの通信に問題があるかサーバー側が落ちている、アクセスするIPアドレスに誤りがある可能性があります IPアドレスの再確認とサーバー側が落ちていないかを下記コマンド等で確認する必要があります ※コマンドの結果が問題ない場合は、「通信に問題がある場合(作成中)」を参照してください # プロセスが待ち受ける、バインドするIPアドレス/port等を確認 # 「*」は全IPアドレスで待ち受けている状態です、特定のIPアドレスが表示されることがあります # HTTP ならば TCP *:80, HTTPSならば TCP *:443などのことが多いです sudo lsof -i -P -nn # 出力例 # COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME # snmpd 1364 Debian-snmp 6u IPv4 43174 0t0 UDP *:161 # sshd 1387 root 3u IPv4 68716 0t0 TCP *:22 (LISTEN) # docker-pr 67965 root 4u IPv4 50378714 0t0 TCP *:443 (LISTEN) # docker-pr 67978 root 4u IPv4 49454775 0t0 TCP *:80 (LISTEN) 最後のLISTENの箇所のIPアドレスとポート番号が意図したものであることそもそも意図した行が存在することを確認してください IPアドレスやポート番号が意図と異なる場合はサーバー側の設定に不備があります 行自体が存在しない場合は大抵プロセスが落ちています サーバーの設定等の調査をしてください tcp/udpのポート番号がそれぞれ何用途かはWikipediaや IANAのページ などに書かれているので詳細はそれらを参照ください 「アクセスが拒否されました」等が表示される(Webに限らず) クライアントとサーバーを含む通信経路上でアクセス拒否する設定(ファイアウォール, ACL, iptables等)がされている可能性が高いですまた、サーバー上のプロセスが落ちている場合もこの表示になる場合があります 前項「タイムアウトエラーが表示される」と同様に下記コマンドで調査してください ※コマンドの結果が問題ない場合は、「アクセス拒否されている場合(作成中)」を参照してください # プロセスが待ち受けるport等が問題ないかを確認 sudo lsof -i -P -nn なんとなく重い、特定時間だけ不調になる 原因として思いつくだけでもDDoS, プログラムのバグ, クライアント/サーバーの過負荷, 通信の輻輳, 通信経路上での物理故障, etc... 本腰を入れた調査が必要なので サーバー管理者、ネットワーク管理者を巻き込んで調査してください 調査に当たっては下記の情報が欲しいです 必須 ・具体的な事象の説明 　☓「通信エラーがでている」 　○「画面に□□というメッセージが表示されている」 　○「△回に▲度□□というメッセージが表示される」 　○「動作に■秒かかるようになった」 ・クライアントのIPアドレス 　「192.0.2.123/24」や「192.0.2.123 255.255.255.0」等 ・サーバーのIPアドレス ・サーバーのプロトコル 　TCP/UDP/ICMP等とport番号 ・事象を確認した時間帯 　最低限、一時間単位で正確なものがありがたいです 利用していれば必須 ・クライアントのVLAN番号 ・クライアント名、位置情報等 ・クライアントを接続しているスイッチ名とスイッチのインターフェース番号 ・サーバーのVLAN番号 ・サーバー名、位置情報等 ・サーバーを接続しているスイッチ名とスイッチのインターフェース番号 あれば ・画面のスクショやログのコピー ※秘匿情報以外は加工せず生情報の方がベスト

GMOペパボ株式会社、デベロッパーエキスパートの黒瀧と申します。先月、技育CAMPにて「ブロックチェーンアプリケーション開発入門」というタイトルで講義を行いました。 登壇内容はこちら https://developers.gmo.jp/36511/ Web3の歴史と実際のサービスでの応用について 1990年代のWeb1の時代から現在のWeb3の時代までを振り返り、それぞれのアーキテクチャの基盤となる技術やコミュニケーションの方法を解説しました。Web2.5として、ブロックチェーンネットワークと既存のシステムが共存する形のSUZURIのNFTを利用したグッズ作成の事例も紹介しました。 NFTオリジナルグッズ販売の流れ (SUZURI) ブロックチェーンとスマートコントラクト Ethereumブロックチェーンを中心に、ブロックチェーンについて解説しました。スマートコントラクトやブロックチェーンネットワークの種類、ユースケースなどを取り上げました。アイデンティティに関しては、DID（Decentralized Identifier）として、個人がIDを管理し、必要な情報を適切な範囲で共有できる仕組みを説明しました。さらに、卒業証明のOpenCerts (https://www.opencerts.io/) のような取り組みも取り上げました。 Ethereumのユースケースの紹介 最後に、SolidityとSolidity Compilerの仕組みを解説し、今後の学習リソースとしての環境や書籍を紹介しました。取り上げた資料(一部)は以下の通りです。 Remix https://remix.ethereum.org/scaffold-eth: https://github.com/scaffold-eth/scaffold-ethWEB+DB PRESS Vol.130: https://gihyo.jp/magazine/wdpress/archive/2022/vol130 作って学ぶWeb3: ブロックチェーン、スマートコントラクト、NFTマスタリング・イーサリアム: スマートコントラクトとDAppの構築: https://www.oreilly.co.jp/books/9784873118963/Cryptozombies: https://cryptozombies.io/jp/ 最後に 参加者の皆様から多くの質問をいただき、あっという間の60分でした。Web3に関する取り組みはまだ発展途上ですが、将来的に私たちの生活に密接に関わるテクノロジーとなるでしょう。今回の講義が参加者の皆様の学びのきっかけになれば幸いです。ご参加いただいたみなさま、ありがとうございました。

こんにちは。デベロッパーリレーションズチームの儀部です。携わっているPJでTestimというテストツールをトライアルで導入しましたので、本記事で紹介させていただきます。 Testimとは TestimはAIを利用したE2Eのテスト自動化ツールです。テストの作成・実行・管理が簡単にできるため、テストの作成やメンテナンスにかかる時間を削減することができます。https://www.testim.io/ Autify、mabl、MagicPodなど類似のテスト自動化ツールもありますが、制限があるものの、Testimはフリープランも提供しているため導入してみました。 Testimの主な特徴 スマートロケーター 画面要素を見つけるためにAIが使用され、複数の属性を使用して要素を特定します。デザイン変更や要素の移動などアプリケーションが変化してもテストが壊れにくくなり、テストの信頼性を高めます。 オートメンテナンス Testimの自動保守機能は、画面要素などが変更されたときに自動的にテストケースを更新します。これにより開発者が手動でテストケースを修正する時間が削減できます。この機能によってテストの更新と保守がとても簡単になります。 テスト失敗時の詳細レポート テスト失敗時には詳細なレポート画面が確認できます。失敗した原因に加え、期待値と実行結果とのスクリーンショットの比較やネットワークログなど、テストケースを解析し問題を解決するのに必要な情報が表示されます。 豊富なサポート アカウントのセットアップから拡張機能、TestOpsといった内容まで含まれており、英語版ですがドキュメントは充実しています。また、時差がある中でもチャットの応答が遅すぎることはなく、手厚くサポートしてくれます。 Testimの使い方 簡単な使い方の流れをキャプチャー交えて説明します。 セットアップ アカウント（メールアドレス・パスワードを入力）を作成後、下記のChrom拡張機能をインストールします。https://chrome.google.com/webstore/detail/testim-editor/pebeiooilphfmbohdbhbomomkkoghoia テストケース作成 右上の赤い「Start recording」ボタンをクリックする。 テストケース編集画面 URLを入力する。 URL入力モーダル 新規でブラウザが立ち上がり、右下にレコーディングしている旨のメッセージが表示される。※フリープランはブラウザにChromeしか選択できないので注意 レコーディング画面 あとは検索ボックスへの入力やボタンのクリックなど、ユーザーの動きをレコーディングしてくれます。レコーディングを終了したい場合は、右下の赤い停止ボタンをクリックします。 テストケース実行 テストケース実行時のデモになります。 実行時のデモ 検索後に表示したページは私が以前記載したブログになります。拙い文章で恐縮ですが、お時間ある方はこちらもお読みいただけますと幸いです。急な宣伝で失礼いたしました(笑) https://developers.gmo.jp/29462/ まとめ 今回はTestimの紹介をさせていただきました。デモの通りで、テストケースの作成～実行まで簡単にできます。また、まだまだ便利な機能があるので、もっと使ってみたいと思いました。 AIが使用されている かつ フリープランの場合は無料で使えるので、とても便利なツールだと感じました。ぜひ皆さまも導入されてみてはいかがでしょうか。

9月1日〜3日に早稲田大学およびニコニコ生放送にてハイブリッド開催された技術カンファレンス「iOSDC Japan 2023」のスポンサーセッションにGMOペパボ株式会社の酒井 文也（＠fumiyasac）が登壇しました。セッションでは、ハンドメイドマーケット「minne」のiOSアプリ開発における歴史や現状の取り組みについて紹介しました。 登壇者 酒井 文也　＠fumiyasacGMOペパボ株式会社  minne事業部 プロダクト開発チーム シニアエンジニア https://speakerdeck.com/fumiyasac0921/minnewotong-zitegan-zitali-shi-tosonoxian-wojian-ju-etaqu-rizu-miyatiao-zhan-nihong-rete 歴史ある大規模サービスを開発・運用することのやりがいと課題 2012年1月に誕生したminneは、ハンドメイド作品を買いたい人と売りたい人をつなぐ国内最大のハンドメイドマーケットとして成長してきました。minneは、パソコンやスマートフォンを利用して簡単にハンドメイド作品を販売・購入できるプラットフォームであり、作家・購入者の両方をターゲットとしています。 そのため、多種多様な決済方法、ギフトチケット、海外配送、アクセス機能解析など、さまざまな機能があるのが特徴です。また、作品の閲覧やお気に入り追加などの操作の際に心地よいアニメーションや細かなインタラクションを用いるなど、シンプルなUIと作品を活かすための動きや表現に工夫が施されています。 今年で誕生から11年を迎える歴史あるサービスだからこそ、自身の成長や開発のやりがいにつながる面もあると酒井は語ります。 「コードベースが大きく多彩な機能を持つが、大規模な機能開発や運用のノウハウの片鱗に向き合う機会もしばしばある。たとえば、仕組み化や自動化を積極的に推進する取り組みや、パターン化された手順等のアプローチは目を見張るものがある。アプリの性質上、サーバー側での処理連携が必要になるので、Webエンジニアとの積極的なコラボレーションをする機会が多いのも特徴」（酒井） 一方で、「規模が小さいときには問題にはならなかったような部分が、大きな落とし穴になってしまうことがある。修正するコードや設定自体は些細なものでも、その影響がどこまで及ぶのか、現時点だけでなくその先も見据えて検討し、進めていかなければならない難しさ・奥深さがある」と、歴史が長く大規模であるがゆえの課題もあると酒井は指摘します。 先人たちが築いた歴史から学ぶ知見 酒井によると、minneでは「故きを温ねて新しきを知る」という精神が根付いているといいます。酒井は「言い換えれば、現状を正しく把握したうえでその先を見据えた取り組みをするよう実践してきた。これはGitHub上に残っているIssueやPull Requestでも感じることができる。それが今日の開発にもいかされている」と説明します。そのうえで、minne iOSアプリのアーキテクチャに関する全体の方針について紹介しました。 minneのiOSアプリでは、Combineフレームワークを利用したMVVMアーキテクチャをベースにした構成を採用しています。酒井は「この形に至るまでの議論や検討の軌跡が社内に残されていた。先輩社員からオンボーディング時にレクチャーを受けたときに、なぜそうしたかということが明確に言語化されていたのが印象的」とminneの開発に関わり始めた当時について話します。 過去には、Reduxに近い構造を有する単一方向のデータフローで管理する「The Composable Architecture」を検討した経緯もあったといいます。これは、状態管理が複雑で、MVVMアーキテクチャを利用しても大変に感じる場面も少なからずあったことから、選択肢の候補として検討されていました。ただ結果的には、検討および一部画面での試験導入までとなりました。酒井は「私自身、過去にiOSアプリ開発にReduxを利用した経験があったので、実際にこの過程は勉強になった」と振り返りました。 このように、普段から開発や設計に関する議論が活発に行われていることもあり、平素の開発ではドキュメントを交えてコミュニケーションする文化があるといいます。たとえば、minneのiOSアプリ開発では、必要な情報がまとめられたWikiがつくられています。「特に運用やデバック手段に関する知見、アプリ内で用いられている他サービスとの連携部分などは今でも参考にしている」と酒井は説明します。 また、下記は以前に酒井がまとめた決済に関するNotionの抜粋です。 Notionを作成した経緯について酒井は、「minneは、WebやiOSアプリでApple pay決裁をいち早く導入したサービス。Amazon Payやキャリア決済など数々の決済手段を整えていることから、特に複雑な部分について自分の復習も兼ねて概要を改めて確認できるよう整理した」と紹介しました。 「その先を見据えた取り組み」に関する事例 続いて酒井は、自身や先輩社員が実践してきた、あるいは現在行っている「その先を見据えた取り組み」に関する事例を紹介しました。 1. MVVM + SwiftUIへリプレイスする取り組み まずは、SwiftUIへのリプレイスです。現在minneでは、UIKitを利用している画面もまだ多くありますが、いくつかのシンプルな画面から少しずつSwiftUIを導入していく取り組みを進めています。このメリットとして酒井は「View要素関連処理がシンプルになり、読みやすくテストしやすい形にできる余地が大いにある」ことをあげます。一方で、最新のUICollectionViewを活用した処理を使うほうが良いケースもあるため、方針については機能や画面に応じて都度検討しています。現在のSwiftUIでは実現しにくい細かな部分や足りない部分においては、UIKitおよびUIViewRepresentableで補うようにしているといいます。 ここで酒井は、参加者に対して「次の画面のうちSwiftUI製の画面はどれか」というクイズを出題しました。 正解は、「注文内容確認」画面です。これは、minne iOSアプリで購入を確定する際に表示される画面です。酒井は「表示要素が多い画面でも、SwiftUIが利用できる余地は増えていると感じている。バージョンやデザイン面での制約を受ける場合はあるが、メリットも大きいので引き続き取り組んでいく所存」とコメントしました。 実際に酒井がSwiftUI＋MVVM構成へリプレイスした際の解説記事が下記のブログにて公開されています。興味のある方はこちらもあわせてご覧ください。 minne iOS内のUIKit+MVC構成画面をSwiftUI+MVVM構成へのリプレイスした時の振り返り https://tech.pepabo.com/2023/05/24/minne-ios-refactoring-swiftui/ 2. iOSアプリの基盤部分の変化へできる限り追従する挑戦 現在minneでは、施策と並行しながら、特に機能の根幹を成すものや自動化の要となるOSSについては、動向やバージョンアップを定期的に確認し、できる限り最新のものに追従していくようにしています。具体例としては、酒井の先輩社員が対応したというApollo iOSのver0.xからver1.xへのバージョンアップ事例を紹介しました。コマンドラインツールや内部処理をはじめとする抜本的な内容が含まれたかなり大きなアップデートだったといいます 3. 施策や調整時のデザイナー・Webエンジニアと積極的な関わりや共同作業 施策や調整時においては、モバイルアプリ担当者はもちろんですが、デザイナー・Webエンジニアとの連携が求められる場面も多くあります。酒井は「積極的な共同作業も忘れてはいけない大事な要素」と付け加えます。minneでは、iOSアプリ開発のエンジニアのなかにもRuby on RailsやGraphQL、Next.jsといったWebアプリの知見や経験を持つメンバーがおり、モバイルエンジニア、デザイナー、Webエンジニアの三者がコミュニケーションを重ねて良いものを作っていこうとするカルチャーがあります。 その他 ChatGPTを活用したPull Requestのサマライズ minneでは、AIの進化を追っていく動きも試験的に導入しているところです。たとえば、既存のCI環境のワークフローにおいて、Pull Request作成時、Build前にGitHub Actionsでdangerを実行し内容確認をするフローでChatGPTを活用してサマライズを追記するようにしています。つまり、Pull Requestとコードの差分から、どのような変更があったのか文章としてChatGPTが要約して説明してくれるというものです。酒井は「差分が大きい場合は解析ができないようなので不向きだが、細かな修正など内容次第ではかなり確信をついたところまで要約できるようになっている。昨今の変化に可能性を感じている」とコメントしました。 大規模かつ歴史あるアプリの開発に携わることの魅力とは iOSエンジニアというキャリアを軸に経験を積んできた酒井。かつてはバックエンドでの経験もあり、「Ruby on RailsやGraphQLなど、今後はよりサーバー側の機能と連動する部分の理解・知見を積み上げていきたい。また、直近ではAndroidの開発に携わっていたため、iOSとAndroidの共通点または相違点を見極めるための足がかりをつくっていきたい」と今後のビジョンについて述べました。そして、minneという歴史ある大規模なサービスの開発に携わってきた経験を踏まえ、次のように語り講演を締めくくりました。 「これまでの歴史や先人たちが残してくれた知見から学びを得て、未来を見据えた開発に携わっていけることが大規模かつ歴史あるアプリの開発に関われることの醍醐味。もちろん、その過程では大変な面も多々ある。大規模であるがゆえの課題もあるが、そこに向き合い、知見からヒントを得て、次につながるものにしていくという取り組みを進めている。ユーザーへの価値提供、そして良き歴史を残していくということが、私たちのチームにおけるこれからの使命」（酒井） アーカイブ 映像はアーカイブ公開しておりますので、まだ見ていない方、もう一度見たい方は 是非この機会にご視聴ください！ https://www.youtube.com/watch?v=sRnEXlPTZ0A

皆さんお久しぶりです。中村です。昨今はAI関連の技術の進歩が目覚ましいですね。今回は上記に関連して、会社の制度をふるふるに使って高性能GPUを買ったり/貸してもらったお話をさせていただこうと思います。 そもそもGPUって？ GPU（Graphics Processing Unit）は、コンピュータのグラフィックス処理を担当する半導体チップのことを指します。元々は、コンピュータゲームや動画再生などの高度なグラフィックス処理を効率的に行うために開発されました。GPUは多数の計算を同時に行うことが得意で、並列処理に特化しています。近年では、GPUの計算能力が高まったことで、グラフィックス以外の用途にも利用されるようになりました。特に、ディープラーニングや機械学習の分野でのデータ処理において、GPUはその高速な計算能力を発揮しています。GPUは現代のコンピュータ技術において、多岐にわたる用途での活躍が期待される重要なコンポーネントとなっています。by chatgpt で、GMOインターネットグループはどんな制度があるんですか？ GPUレンタル こちらは高性能GPUを貸りることができる制度です（期間は要相談）AI関連技術の採用推進をグループとして推していることもあり、学びやすい環境が整っています。 【パートナー向け「NVIDIA H100」および「NVIDIA L4」搭載サーバーの無償貸出】AI関係の研究開発・活用促進を目的に、NVIDIA社の最新GPU「NVIDIA H100」、「NVIDIA L4」を搭載したサーバーの短期間のグループパートナー向け無償貸出を開始します。これにより、新規サービスの実証実験や研究開発をスピーディーに行うことが可能になります。なお、GPUホスティングの環境は先に発表した（※1）「ConoHa for AI」と同等のもので、社内でのフィードバックを製品の質の向上につなげます。また研究開発やローカルでの画像生成AIの活用促進として、NVIDIA GeForce RTX™4090またはNVIDIA GeForce RTX™3080Tiを搭載した高性能ゲーミングノートパソコンもグループパートナーに対し短期貸出を開始し、トライアル利用の後、GMO インターネットグループ株式会社では同様のスペックのマシンを長期貸出可能にいたしました。GMOインターネットグループ株式会社他、グループ各社でのAI関連開発用機材としての採用を推進します。 詳細：https://www.gmo.jp/news/article/8454/ エンジニア支援制度（学ぼうぜ） こちらはGPUにかかわらず自分のスキルアップに繋がるものであれば使用可能な制度です。自分は資格取得やガジェットが多いですが、人によっては遠方勉強会の参加費等で利用する方もいます。 #スキルアップ補助制度「学ぼうぜ！」技術関連の書籍や最新ガジェットの購入、開発合宿への参加費など、スキルアップに繋がる事項にかかる費用を、年間10万円まで補助するプログラムです。エンジニア・クリエイターのスキルアップに対するモチベーションの向上を図るとともに、得た成果やスキル・ノウハウを社内で共有し合うことで、GMOインターネットグループ全体の技術力の向上を目的としています。 内容スキルや役職に関わらず、1人につき年間10万円までを補助補助対象技術書の購買、技術系雑誌の講読費用最新ガシェット機器個人利用・個人名義の機器購入費用の50％　※通信費は個人負担　会社支給のスマートフォンなどの買換えは全額補助研究対象とする他社サービスの利用料金開発合宿への参加費条件レポートの提出（効果・成果、得られたスキル・ノウハウの共有） 詳細：https://www.gmo.jp/csr/human-capital/engineer/ どっちの制度使ったの？ 結論どっちも使いました！ GPUレンタルで借りたGPU 個人では気軽に使えないようなGPUを借りました！条件にもよりますが画像生成AIなどの処理が数秒で終わるレベルのものです。 L4(データセンター向けGPU)RTX4090 16GB(Laptop version) Nvidia L4 RTX4090 Laptopシリーズ エンジニア支援制度（学ぼうぜ）で買ったGPU 個人では気軽に使えないようなGPUが自宅にも欲しいと思ってしまったので今年の補助を全部突っ込んで購入しました。 RTX4090 24GB(デスクトップPC用) ZOTAC GAMING GeForce RTX 4090 AMP Extreme AIRO White Edition そのGPUは何に使ったの？ 画像生成AIの生成速度比較などを試していました。画像生成AI（StableDufusion）については長谷川さんの記事が参考になるので是非どうぞ！ https://developers.gmo.jp/22831/ インフラサマーインターン 折角なので学生の方にも最新技術に触れられるようにインターンのカリキュラムに盛り込みました。実機を会場に持ち込み、目の前で動いている環境を構築しています。 手前：GPUレンタルで借用したRTX4090ノートPC、奥：学ぼうぜで購入したRTX4090導入したデスクトップPC 今回のカリキュラムでは、【作りたいものをイメージ→プロンプト作成→画像生成→振り返り】を繰り返し行い、画像生成AIを通してチームを表すフラッグを作ってもらいました。 気になった方はConoHa for AIをチェック！ ConoHaでも高性能GPUが使用できる仮想サーバーサービスが発表されています！サービスリリースはまだですが、気になる方は是非チェックよろしくお願い致します！https://www.conoha.jp/ai/teaser/

こんにちは、暗号のおねえさんことGMOインターネットグループ デベロッパーエキスパートの酒見(@ysakemin)です。2023年7月22日〜28日、アメリカ・サンフランシスコでInternet Engineering Task Force (IETF) 117 に参加しました。今回の参加目的としては、IETF117でHackathonに参加すること、IETFにおける暗号技術の動向を調査することです。Hackathonでは低遅延暗号 Areion に関するプロジェクトを立上げたので、今回の記事ではその話題に触れたいと思います。 イベント概要 The Internet Engineering Task Force (IETF)とはIETFは、インターネット技術の標準化を行う団体です。 これまで、HTTP、IP、TCP/UDP、TLS、QUICなどインターネットで使われる多くのプロトコルが標準化されてきました。オープンな組織であり、会合には誰もが参加可能です。活動の生産物として、RFC(Request for Comments)を発行されています。IETFの詳細については、こちらをご参照ください。 以下は、本記事で取り扱う2023年7月に開催されたIETF117の概要です。 イベント：IETF117開催日時：2023年7月22日（土）～28日（金）開催場所：カリフォルニア州サンフランシスコ ヒルトンユニオンスクエア　　　　　オンラインのハイブリッド主催：NOKIA（ノキア） 活動の背景 今回のHackathonでは、低遅延暗号 Areion に関する活動を行ったのですが新規にテーマ登録して参加を行なったので、この活動を実施する上でのノウハウも書かせていただきたいと思います。 この活動の背景としては、NICT Beyond5G研究開発促進事業 委託研究の「リアルタイム暗号技術とプライバシー保護への拡張」があり、この研究テーマでは低遅延暗号Areionをインターネット上で利用できるような環境を増やすことがミッションの一つとなっております。気になる方はこちらのURLを確認してくださいね。 ＜ノウハウ1＞ Hackathonでの「最初の一歩」 Hackathonに参加する際には、IETF Hackathon Wiki の中から興味のあるテーマを見つけるのですが、今回のわたし達のテーマは立ち上げが必要です。 テーマを立ち上げるためには「Champion」になる必要があります。「Champion」とは、テーマの主催者であり、Championとして登録することはテーマを主導していくことの宣言となります。 Championになる方法は簡単で、Hackathon Wikiに下記のような内容を記入するだけです。 ### Your Project Name - **Champion(s)** - Your Name (email at domain.com) - **Project Info** - Your project description here なお、Hackathon Wikiの記入はIETF Datatracker accountの取得が必要となるため、ご注意ください。 例えば、今回の低遅延暗号 Areion ですと、Wikiへの記載例は以下のとおりです。 ＜ノウハウ2＞ Hackathon当日の場所取り Hackathon当日のChampion のミッションとして、お花見でいうところの「場所取り」があります。会場には大きなテーブルがたくさんあるので、どの席がいいか？などを考えて場所を決めます。場所の取り方は原始的で、ホワイトボードの空きテーブルと実際の空きテーブルを確認しながら、確保できそうな場所にテーマ名を記入します。私たちのテーマだと、以下のような感じで確保することができました。 テーブルが確保できたら、テーブルに立て看板が用意されているので、そこにテーマ名を出して場所取り完了です。 今回、いい感じの場所を獲得することができたのですが、真夏のサンフランシスコだったにも関わらず、エアコンの吹き出し口の真下な席で寒すぎて体調を崩したので…次回からはその辺も気にして場所取りしたいですね！ 陣地も獲得できたら、あとは計画していたHackを進めていきます。 Hackathonの2日目に成果発表会があるため、目標を達成して良い報告ができるように活動に取り組んでおりました。成果発表の時間は、IETF Hackathon Wikiにテーマ登録を行い、専用のGitHubリポジトリに登録することで枠をもらえます。 今回のHackathonでの活動 今回は、Areionのリファレンス実装のOpenSSLへの組み込みを行い、TLS1.3でAreionを使えるように対応を行いました。 Areionを組み込んだOpenSSLの実装と発表資料は以下のとおりです。 実装はこちら。発表資料はこちら。 Hackしている時や発表後にコメントやアドバイスを多くいただけたので、今回は大成功だったと思っています。 今後の取り組み 今後は、2023年11月4日から開催されるIETF118に向けて活動を準備していきます。引き続きよろしくお願いします。 当社では、先端技術を用いたコア実装、調査研究、実証実験などの研究支援から、標準化支援、エンタープライズ向けサービス開発まで積極的に実施しておりますので、お気軽にお問合せください。 お問い合わせはこちら

先日開催された、セキュリティ・キャンプ 全国大会 2023に、GMOインターネットグループはシルバーメンバーで協賛しました。当日は企業紹介イベントへの参加や、GMOインターネットグループの社員が講師として参加してきましたので、その内容をレポートしていきます！ イベント概要 セキュリティ・キャンプ全国大会とは 「セキュリティ・キャンプ」のメインイベントとして主に夏休み期間中に実施する合宿形式の勉強会です。 毎年テーマ別に集められるエキスパートが講師となり、専門的・実践的な講義が受講できるほか、合宿の中で同じ趣味を持った仲間との交流もあります。全国大会のほか、全国大会修了生の次のステップとなるネクストキャンプ、小中学生を対象としたジュニアキャンプも同時開催いたします。また会期中には、これまでにセキュリティ・キャンプに参加した修了生がチューターとして学習の支援等も行います。 開催日：2023年8月7日（月）～8月11日（金）開催場所：クロス・ウェーブ府中参加費：無料（事前登録制）主催：独立行政法人情報処理推進機構（IPA）、一般社団法人セキュリティ・キャンプ協議会公式HP：https://www.security-camp.or.jp/IPA HP：https://www.ipa.go.jp/jinzai/security-camp/2023/zenkoku/index.html 会場となるクロス・ウェーブ府中は、勉強する部屋、食堂、ホテルがすべて建物内に入っており、学生たちは過ごしやすそうで勉強に集中しやすい環境が整ってました。 「このはちゃんポーチ」使ってくれたかな？！ 参加者には、各協賛企業からのノベルティが事前配布という形で各自宅に郵送されました。 GMOインターネットグループからは、合宿期間中に使用できるようにと、小物類など持ち運びに使える『このはちゃんポーチ』をプレゼントさせていただきました！！ 弊社のホスティングサービス「ConoHa by GMO」のキャラクターである”美雲このは”です。是非たくさん使ってくださいね～！！ 企業紹介イベント 今回は現場で活躍するエンジニアと人事が参加させていただきました。 前半は人事より、会社説明や働く環境について詳しく説明させていただきました。後半はセキュリティに携わるエンジニア2名より、実際に行っている業務内容や働いていくうえでのモチベーションなど、なかなか聞けないリアルな現場の話をお話しました。 最後の質問タイムではたくさんの声をいただき、有意義な時間になったのではないかなと思います。 参加してくれた方にはGMOオリジナルノベルティをプレゼントさせていただきました！ GMO講師 GMOインターネットグループより、講師として複数名参加いたしました。実際に参加してみての感想やインタビューをいただきました！ GMOペパボ株式会社 紫関 麗王 開発コース│Z2『Rust製Linux向けアンチウィルス実装ゼミ』 Q：全国大会の講師を終えての感想 紫関セキュリティ・キャンプ全国大会には2020年に受講生としてオンラインで参加したため、オフライン会場での参加は初めてでした。今回は講師という立場での参加でしたが、受講生と共に、自分も多くの事を学びました。 Q：学生へのメッセージ 紫関セキュリティ・キャンプは恐らく来年も開催されるでしょう。密度の高く、熱量もある濃密な5日間を過ごすことができる貴重なイベントなので、今年参加できなかった方もぜひ来年またチャレンジしてください。 GMOサイバーセキュリティ byイエラエ株式会社 三村 聡志 専門コース│A4『ローレイヤーから見るファイルシステムの理解』 開発コース│X1『リバースエンジニアリングゼミ』 Q：全国大会の講師を終えての感想 三村今年も昨年に引き続き、専門コースで1講義と開発コースのひとつを担当しました。「ローレイヤーから見るファイルシステムの理解」は、昨年や他のミニキャンプでも行っている内容で、xxd コマンドと grep と電卓だけで FAT32 を読み進めるという講義になります。慣れるまでがとてもハードな内容とはなりますが、今年は終わったあとに「とても楽しかった」という感想をもらう事も出来、私の方もとても楽しかったです。また「リバースエンジニアリングゼミ」は本業で行っている IoT ペネトレーションテストをそのまま一週間行うような講義になっています。全国大会の講師は昨年に引き続きとなりますが、参加者の知識や感性が異なるため、毎回新しい発見や刺激があってとても楽しいコースと感じています。来年も機会があれば引き続き担当出来たらと思っています。 Q：学生へのメッセージ 三村ものごとの仕組みを知る、基礎を知るというのはとても大事なことだと考えています。「USB端子に機器を接続すれば繋がる」ということは知っていても、機器が使えるようになるまでにどのような通信が行われているのか、機器が繋がったことをどうやって知るのか、などそこには通常知られていない様々な技術が隠れています。仕組みを深く知るためにはそれなりの時間や手間が掛かりますが、知ることができればそこから新たな世界が見え、新たな活用方法・攻撃手法の発見に繋がっていきます。是非学生のうちに、ものごとの仕組みや基礎の学習・調査を進め、ワクワクがあふれ出るエンジニアに皆さんがなられることを願っています。 GMOサイバーセキュリティ byイエラエ株式会社 緑川 志穂 開発コース│L1『暗号化通信ゼミ』 Q：全国大会の講師を終えての感想 緑川講師を拝命するのも6回目になりますけれども、受講生の方々のバイタリティには毎年驚かされるばかりです。そして久々のオフライン開催はオンライン指導との違いを改めて感じさせてくれました。開発コースではしばしば事前学習期間に極めて高い比重を置きますし、私の担当したゼミも事前学習期間が寧ろメインの指導期間となっていました。それでもオフラインで開催された5日間は事前学習よりもひときわ濃い印象を残したと感じます。叶うなら来年も是非オフラインで参加したいところです。 Q：学生へのメッセージ 緑川閉講式で言われたことを覚えておられるかもしれませんが、キャンプ修了後に重要なのはモチベーションの維持です。でも本記事の投稿の頃にはそろそろ一度息切れする頃かとも思います。五線譜に描かれる休符に無駄なものが無いように、休むこともまたモチベーションへと寄与します。キャンプ以降幾星霜が経過しても能力を発揮し続けられるよう、頭に留めてもらえると幸いです。 GMOサイバーセキュリティ byイエラエ株式会社 西谷 完太 / 山崎 啓太郎 専門コース│B6『ソースコード解析によるWebアプリケーションの脆弱性調査』 Q：全国大会の講師を終えての感想 西谷去年講義を行った「マイクロサービス／分散モノリス的アーキテクチャへの攻撃手法」では、近年普及が進んでいるクラウドサービスやマイクロサービスアーキテクチャを題材にした各サービス連携時に発生する脆弱性を使った攻撃手法を取り扱いました。今年の講義は「ソースコード解析によるWebアプリケーションの脆弱性調査」ということで、よりアプリケーション単体のロジックにフォーカスし、ソースコードの静的解析による脆弱性調査の楽しさや開発者自身が原因の特定などに役立ててもらうための内容を盛り込んだ内容となっています。また、CodeQLなどWebセキュリティの中でも比較的新しいトピックを講義内容に盛り込んでいるので学生だけでなくエンジニアが興味を持って取り込める内容だと思いますので、興味があれば今後公開予定の資料を覗いて取り組んでもらえると幸いです。 山崎講義は手動でのソースコード解析とツールによる自動化という内容で行いましたが、比較的実践的な内容になったかと思います。専門Bコースでは本講義の他にもWebプロダクトのセキュリティーやその周辺に関連した講義から構成されており、どれも社会人にとっても面白い講義だったのが印象的でした。 Q：学生へのメッセージ 西谷各プログラミング言語やソースコードリーディングだけでなく、様々な知識を必要とする講義で取り組むのが非常に大変だったと思います。ただ、その中でソースコードの静的解析による脆弱性調査の楽しさや開発者自身が原因の特定など、あなた自身のやりたいこと、やっていることに少しでも役立てていただければ幸いです。 山崎今回の講義の後半ではソースコード解析ツールを利用してクエリを書いてもらいましたが、実際には開発者の意図や状況を想定して人間がソースコードや設計書を読み、動作を検証しなければ見つかりづらい脆弱性がまだまだ多く存在しますし、今後も必要とされるスキルだと思います。ソースコードを読んでバグを探す時には様々な知識や経験が役に立つので、本講義が自身の興味を広げたり新しい知識を得る一助になっていると嬉しいです。 ▼講義資料はこちらhttps://gmo-cybersecurity.com/news/security_camp_presentation_slide_20230912/ さいごに セキュリティ・キャンプ全国大会2023にご参加された学生の皆さま、5日間の勉強合宿、大変お疲れさまでした！！皆さんの今後の頑張り・活躍を応援し期待しております！

こんにちは、GMOインターネットグループ株式会社の小林です。今回はセキュリティ対策の一環で導入しました、Yubileyについてご紹介させていただきます。 導入背景 以前よりMicrosoft365を導入していましたが、元々はID/PASSでの認証でした。それでは脆弱な状態であると判断し、全パートナーにスマートフォンを配布して多要素認証を導入しました。しかし、コールセンターや特定の業務のみに従事している場合は多要素認証のためだけにスマートフォンを配布するため一定のリスクが伴います。そのためID/PASSのみの認証にはならずに多要素認証を実装できるYubikeyの導入を決めました。 Yubikeyとは Yubikoという会社が開発したセキュリティキーで、用途に応じて複数の種類が発売されています。今回導入したのは以下画像にあるUSBのような形状のものになります。 種類についての詳しくは日本の公式代理店であるソフト技研のサイトを参考にしてください。 導入方法 Yubikeyが使用できるサービスは様々ありますが、今回は全パートナーに導入済のMicrosoftアカウントの認証に実装してみました（多要素認証を実装するためには事前にMicrosoftのライセンス及びMicrosoftアカウントの設定が必要になりますのでご注意ください） 簡単にユーザーが使用を開始できるまでの方法をご紹介させていただきます。 ①Yubikeyのソフトウエアを使用するPCにインストールします（Yubico Authenticater）②PCにインストールされたYubico Authenticaterを起動します。 ③Yubikeyデバイスをパソコンに接続します。 ④Yubikeyを接続するとアプリが以下の画面に代わります。　「三本リーダー」をクリックします。 ⑤「Add account」をクリックします。 ⑥以下のリンクをクリックし、Microsoft365のセキュリティページにアクセスします。　Microsoft365マイアカウント-セキュリティ確認　「＋サインイン方法の追加」をクリックします。 ⑦「認証アプリ」を選択し、「追加」をクリックします。 ⑧「別の認証アプリを使用します」をクリックします。 ⑨「次へ」をクリックします。 ⑩認証アプリのQRコードが表示されます。　㋐Yubico Authenticaterの「Scan QR code」をクリックします。　㋑Yubico Authenticaterの「Require touch」をクリックします。　㋒Yubico Authenticaterの「Save」をクリックします。　㋓認証アプリの「次へ」をクリックします。 ⑪Yubico Authenticaterにメールアドレスを登録されます。　㋐Yubico Authenticaterに登録されているアカウントの「指マーク」をクリックします。　㋑Touch requiredというメッセージが表示されますので、Yubikeyデバイスの金属部分をタッチします。　㋒認証の番号が表示されますので、認証アプリの「コード入力」場所に入力します。　㋓認証アプリの「次へ」をクリックします。 ⑫認証アプリの登録が完了するとセキュリティ情報に認証アプリが表示されます。 利用方法 次回以降、再認証がMicrosoftのログインページで求められる際はパスワード認証の後に以下の認証が求めらます。表示されたらYubico Authenticatorからコードを取得して入力してログインできれば認証完了となります。 ※Yubico Authenticatorのコードを確認する方法 ①Yubico Authenticatorのアプリを起動します。 ②Yubicoアプリに登録されているアカウントの「指マーク」をクリックします。 ③以下の画面が表示されますので、「Calculate」アイコンをクリックします。 ④「Touch required」のメッセージが表示されます。 ⑤Yubikeyデバイスの指定した場所を「タッチ」します。 ⑥Yubico Authenticatorの認証コードが表示されます。 まとめ Yubikeyの設定自体は簡単で、仕様を理解していれば短時間で導入可能です。 実際の多要素認証の場面では物理的に触れることで認証されるため、業務で利用するパートナーにとっても理解しやすいものとなります。導入によりスマートフォンを使用する多要素認証よりも問い合わせが少なくなり、IT部門と利用者の双方の負担が軽減され、時間とリソースを節約することもできます。ご参考になれば幸いです。

こんにちは、GMOインターネットグループ株式会社の河﨑屋です。今回はOJT（実務研修）の一環で新卒の方々と一緒にイベントストーミングを行った話をご紹介します。 710プログラムとは 現在GMOインターネットグループでは、新卒世代で最高のポテンシャルを秘めた人財に集まってもらうべく『新卒年収710万円プログラム』を実施しております。（初任給・給与ナンバーワン~新卒年収710万プログラム~） 従来の新卒パートナーの倍以上のパフォーマンスを発揮できる優秀な人財に対して年収710万円（2年間）をお約束するものです。将来的にはグループ会社の社長や各事業の責任者など、今後のGMOインターネットグループをリードする「リーダー人財」を目指していただきます。ぜひ興味のある学生の方はご確認ください。 参加者 本OJTには下記メンバーにご参加いただきました。筆者は②の商材システムの開発運用を行うエンジニアとして参加しました。 ①2023年にご入社いただいた710プログラムの新卒パートナー（以下 710新卒と呼称） ②ドメインエキスパート（商材システムの開発運用に従事しているエンジニア） ③ファシリテーター（会議の進行や参加者から質問を引き出す役） 今回のOJTの目的 イベントストーミングの目的としては710新卒の方々にイベントストーミングを通じて商材に関する知識を身に着けてもらうことと、エンジニアと協創するという経験から実際の業務でも円滑に進められるようなリレーションの構築を促すことです。 イベントストーミングとは イベントストーミングは、特定の「ドメイン」、すなわち問題を解決しようとしている特定の領域やビジネスロジックなどを理解し、モデル化するための手法です。ここでの「モデル」とは、現実世界の複雑な部分をシンプルに表現したものです。 今回のイベントストーミングはGMOインターネットグループ内で普段使用しているフォーマットを踏襲して進めていきました。ここでは詳しい説明は省きますが、興味のある方は以下の資料をご確認いただければイメージを掴めるかと思います。 参考資料：イベントストーミング&イベントソーシング入門 イベントストーミングのモデル例 新卒OJT版イベントストーミングの進め方 今回の研修では、主に3つのセグメント（ドメイン事業・ホスティング事業・アクセス事業）の代表的な商材をイベントストーミングの対象として実施しました。 なお、以下に示す例は実際に作成したものとは異なり、今回の執筆に伴い筆者の方で新たに作成したものになっています。ここでは、レンタルサーバーのサービスにフォーカスを当てています。 イベントの洗い出し 最初に想定しうるイベントを洗い出すことを行いました。710新卒の方々はプロダクトの仕様に関してまだ詳しくなかったので、システムの裏側を理解しているドメインエキスパートと対話しながら進めていきました。 洗い出されたイベントの一例 時系列の整理 次に、洗い出したイベントを時系列で整理しました。この段階でイベントが適切なものか、重複はないかなどの精査も併せて進めました。 時系列にまとめられたイベントの一例 懸念点・問題点の洗い出し 時系列で整理していくと、イベント単位で気になることや前後のイベント関係が不十分な箇所が出てきました。その部分をホットスポットとして、メモに記録しておきました。 留意事項をホットスポットで記載 モデルの構造化 イベント以外にも、コマンド、ポリシーなどの概念を加えて、モデルの構築を進めました。この段階で、ホットスポットに対して深掘りし、慎重に解決策を探りました。 構造化されたイベントストーミングの一例 やってみて感じたこと イベントストーミングは特別なスキルセットが必要なく、様々な属性を持つステークホルダーと共通理解を作り上げる手法だと説明されています。確かに今回参加した710新卒の方々はプロダクトの仕様をほとんど知らない状態から始め、自分たちの言葉で仕様を説明できるというレベルにまで到達することができました。 ですが、課題点もいくつか見受けられたので、こちらを共有します。 まず710新卒の方々を苦しめたのはドメインエキスパートが使う言葉でした。システム開発の経験がほとんどない710新卒の方々にとって、サービス、バッチ処理、API、DBなどの用語は混乱の元でした。それを察知して、少しでもイメージしやすいようにという気持ちから、ドメインエキスパートが曖昧な表現をしてしまい、さらなる混乱を生む場面もありました。 仕様を深堀りする、解像度を揃えるという作業には、高いコミュニケーション能力と、物事を構造的に把握する能力がとても重要に感じました。言葉の意味を注意深く察知し、「VMってなんだ？？」「レジストリとレジストラって一緒ですか？？」など積極的に質問している姿はとても印象的でした。 仕様を共有するドメインエキスパート側の姿勢も重要でした。システムの仕様を説明する際、どういった経緯で今の仕様を採用しているのか、身近なエピソードや具体例を交えて説明するなど、抽象と具象のバランス感覚を身につけることで、より深くシステムの概念やプロセスを共有できると感じました。 まとめ 今回筆者はドメインエキスパートとして参加しましたが、710新卒の方々とともに自分たちのサービスを見直す機会はすごく刺激的でした。「どうしてこんな構造なんだろう？」「ここはなぜ共通化できないんですか？」など出来上がったシステムだけを見ている私では気にも留めないようなことが、外から見ると目立ち、改善のヒントになることを新たに発見しました。 イベントストーミングはDDDにおけるモデル設計手法の一つというイメージが強かったのですが、今回のように開発者以外の方ともサービスの現在地点を共有し、新たな視点や知識を創造するための有効な手段になりうると感じました。 ぜひこの記事を読んでいただいた皆さんもイベントストーミングの魅力に触れてみませんか？可能性を探求し、創造の旅へ一歩踏み出しましょう。新たな視点を開拓するチャンスを掴んでください！

6月24日（土）に福岡ファッションビルにて開催されたPHPのイベント「PHPカンファレンス福岡2023」にGMOペパボ株式会社 小山健一郎（@k1LoW）が登壇しました。セッションでは、小山が開発するtblsというツールを題材に「Documentation as Code」という考え方について解説していきました。 登壇者 小山 健一郎　＠k1LoWGMOペパボ株式会社 技術部 技術基盤チーム https://speakerdeck.com/k1low/phpconfuk-2023 tblsとは ドキュメント運用の1つのアプローチであるDocumentation as Code（その一部はhttps://speakerdeck.com/k1low でみることができます）。そして、Documentation as Codeを実現したツールがtblsです。 tblsは、データベースからドキュメントを生成するCIフレンドリなツールであり、データベースに接続してER図付きのマークダウン形式のドキュメントを生成します。2018年5月17日より開発がスタートしており、PostgreSQL、MySQLをはじめとするRDBMSのほか、BigQueryやAmazon DynamoDB、Cloud Spannerなど14のデータソースに対応しています。 Documentation as Codeとは ドキュメンテーションについてのコミュニティである「Write the Docs」において、Documentation as Codeとは、「コードと同じツールを使ってドキュメンテーションを書くべきだという哲学」と定義されています。小山はこの定義に対し「システム開発の近くにドキュメント作成の仕組みを置くことで、開発サイクルのなかにドキュメント作成を統合して、システムとドキュメントの乖離を少しでも小さくしようという考え方だと思っている」と、自身の解釈について説明します。 ただし、システムとドキュメントの乖離を小さくするという考え方のみでは、実用に耐えない場合もあると小山はいいます。 「たとえば、システムのアーキテクチャを説明しているドキュメントにはAと書いてあったのに、現場の人に聞いたら『それは先週Bになった』といわれてしまうケースが考えられる。こうして開発時にドキュメントとの乖離があると手戻りが発生するおそれがある。すると、誰もドキュメントを信用しなくなり、読まれなくなる。結果として、ドキュメント更新のモチベーションが低下し、システムとドキュメントの乖離がさらに広がるという負のループに陥る。かといって、システムは日々開発が進むため、機能追加や改修の際、常にドキュメントと一緒にPull Requestを出せるかというとそうではない。ドキュメントをレビューするタイミングがないというのも課題になる」（小山） システムとドキュメントの乖離をゼロにする「Documentation as Code+」 そもそもシステムとドキュメントの乖離はなぜ起こるのでしょうか。小山は、「システムは時間の経過によって変化するが、ドキュメントはその変化に追従しない、もしくは追従するにもタイムラグが発生するため」と説明します。そして、「時間経過に耐えうるには、システムを都度そのままドキュメントに変換できればよい」とします。この結論は、実際に小山がモデル化して導出し、確認したといいます。さらに、システムをそのままドキュメントに変換するには、「システムからドキュメントのもとになる構造化データを抽出できればよい」と指摘する小山。「これにより、システムとドキュメントの乖離をゼロにできると考えた」と述べます。 （参考）「システムの変化に追従可能でかつ理解し易いドキュメントシステムのモデル化」 https://speakerdeck.com/k1low/web-system-architecture-number-8 このように、システムとドキュメントの乖離をゼロにするというアプローチを取るDocumentation as Codeを、本セッションでは便宜上、本来のDocumentation as Codeと区別して「Documentation as Code+」と呼びます。 Documentation as Code+のアプローチは大きく分けて2つあります。1つめは、システムから構造化データを抽出し、その構造化データからドキュメントを生成するというもの。PHPDocやGodocといったソースコードからドキュメントを生成するアプローチがこれに相当します。 2つめは、構造化データからシステムとドキュメントの両方を生成するアプローチです。これは、OpenAPIやProtocol Buffersのprotocなどがそれに相当します。 ドキュメントの活用範囲を広げる「Documentation as Code++」 tblsは、構造化データ（データベース）を抽出してドキュメントを生成するアプローチ、つまりDocumentation as Code+の視点で作成されていると小山は説明します。 tblsでは、データベースとドキュメントのタイムラグをできるだけなくすために、CIで継続的にドキュメントを生成すること=継続的ドキュメンテーションが推奨されています。tblsはワンバイナリで簡単にインストールでき、CIフレンドリであることが特徴です。 （参考） 「CIフレンドリなDBドキュメント生成ツールでドキュメントの最新を維持し続ける」 https://speakerdeck.com/k1low/phpconfuk-rej （参考） 「Continuous Documentation - CI/CDパイプラインを活用した文書化技術」 https://speakerdeck.com/k1low/pepabo-tech-conference-number-16 ただ、運用していくなかでは、Documentation as Code+にも課題があることがわかってきたとする小山。「tblsによって正しいデータベースドキュメントであるという安心感は得られたが、システムの開発ライフサイクルにおいて役に立つタイミングが少なく、作成して満足している状態になってしまっている」と説明し、その理由と対策の方針について次のように考察しました。 「データベースのドキュメントの情報だけでは足りないのかもしれないと考えた。データベースから抽出した情報以外の情報もあったほうがよい。また、ドキュメントの形式がマッチしていない可能性もある。正しいデータベースドキュメントは正しいデータであるため、データ活用の接点を増やしたほうがよいのではと考えた」（小山） このようにドキュメントの活用範囲を広げる方針を、便宜上「Documentation as Code++」とします。 ドキュメントにアノテーションを付与する Documentation as Code++のアプローチとして、まず、情報が足りなければ足していくという考え方について具体的に考えてみます。 小山は、ソフトウェアアーキテクチャの世界にあるビューやビューポイントといった考え方をもとに、ある1つのアーキテクチャをさまざまな切り口で表現することで全体を理解すればよいという考え方を紹介します。 「関心事にあわせてアーキテクチャを1つ以上の側面で表現するという考え方は、設計だけでなくドキュメンテーションにも当てはめることができる。ビューやビューポイントのスコープは、そもそもドキュメントにも入っており、関心事にあわせて必要なシステムの要素だけをまとめてビューとしてドキュメント化してみてはどうかと考えた。実際に、システムアーキテクチャをドキュメントするためのツールを作成するなどして効果を実感している」(小山) （参考）「目的に沿ったDocumentation as Codeをいかにして実現していくか」 https://speakerdeck.com/k1low/phperkaigi-2021 tblsには、スキーマやテーブルのカラムにラベルを付与できるラベルという機能があります。ラベルはそのままドキュメントや構造化データにも反映されます。たとえば、GMOペパボでは、漏洩してはいけない情報に”sensitive”というラベルを付与し、マスクしたり権限を限定したりといった用途で活用しています。 また、最近では、関心事にあわせてテーブルやラベルを絞り込み、その関心事を説明するためのドキュメントを別途作成するviewpointという機能もtblsに追加されました。.tbls.ymlファイルにviewpoointを追記して利用します。小山によると、さらにグルーピングなどによってよりわかりやすくするような機能も作成しているといいます。 中間的な構造化データを活用する ドキュメントの形式がデータベースにマッチしていないかもしれないという課題に対しては、ドキュメント以外のアプローチを考えていきます。 tblsでは、v1.57.0からtbls docでschema.jsonがデフォルトで出力されるようになっています。schema.jsonは、データベーススキーマと.tbls.ymlを利用してドキュメントを生成するために内部で構築される構造化データです。このアプローチについて小山は「デフォルトでschema.jsonが出力されていれば、それがある前提でさまざまな実装ができるという考えが根底にある」としたうえで、詳細について次のように説明します。 「tblsの内部では、MySQLなどのデータベースの情報をそのまま中間データとしてschema.jsonに落としており、実はschema.jsonはデータソースとして使えるような形になっている。つまり、schema.jsonさえ保存しておけば、実データベースに保存していなくてもドキュメントを再生産することが可能となる。この仕組みを活用したのが、tbls ls。データベースのテーブル一覧やカラム一覧を出力するコマンドで、ドキュメントを見に行かなくても、schema.jsonから内容を見ることができるというもの」（小山） LLMの活用可能性 小山は、ドキュメントの適用範囲をさらに広げるためにLLM（大規模言語モデル）を使用している事例についても言及しました。 tblsでは、データベースドキュメントが正しいことがわかっており、コメントやビューポイントなどコンテキストを理解するための情報も多く持っています。この特徴に対しLLMの強みを利用すれば、コメント付きの正しいデータベーススキーマと質問をLLMに与えることで、データベーススキーマとコンテキストに沿ったSQLクエリを生成するといったことが可能となります。小山によると、実験的実装としてtbls askというサブコマンドを作成したといいます。tbls askは、schema.jsonから正しいコンテキストを持ったデータベーススキーマを作成し、内部的にプロンプトに仕様するコマンドです。このようにLLMによって正しいドキュメントを使った推測というアプローチが取れるようになります。 また、小山は、逆のアプローチとして、テーブルのレコードのサンプルを与え、LLMにテーブルとカラムの説明を推測させるということも可能であると紹介しました。 おわりに 小山によると、tblsは、Documentation as Codeについて考えながら継続的に開発してきたツールであるといいます。これを踏まえ、次のようにコメントして講演を締めくくりました。 「Documentation as Codeの原点は、ドキュメントとコードを同じように運用していくという考え方。そして現時点においてDocumentation as Codeは、『正しいドキュメントは正しいデータであり、ドキュメントの範疇を超え良質な入力になる』ものだと私は考えている。ぜひこのアプローチでドキュメントをよりよくしていただければ」（小山） アーカイブ 映像はアーカイブ公開しておりますので、まだ見ていない方、もう一度見たい方は 是非この機会にご視聴ください！ https://www.youtube.com/watch?v=b3TePTDCNgg