こんにちは、イノベーションセンターの松本です。普段はOffensive Securityプロジェクトのメンバーとして攻撃技術の調査・検証に取り組んでいます。 この記事では、我々のチームで開発したレッドチームフレームワーク「GHARF (GitHub Actions RedTeam Framework)」に関する取り組みと、筆者が学生時代に参加したインターンシップから入社を経て Black Hat Europe 2025 のArsenalで登壇するまでに至った道のりについて紹介します。 はじめに インターンシップ記事から2年 本記事の目的と概要 Offensive Securityプロジェクトの紹介 取り組みの着想とコンセプト インターンシップ時点のアイデア GitHub ActionsのCI/CD機能を攻撃基盤として活用する 「GHARF」の技術解説 GHARF (GitHub Actions RedTeam Framework)の概要 特徴と機能 アーキテクチャ 倫理的配慮について 世界の舞台での登壇 登壇したカンファレンス CODE BLUE / Black Hat Europe CODE BLUEとは？ Black Hat Europeとは？ 発表内容 ロンドンでのデモ発表とその反応 おわりに はじめに インターンシップ記事から2年 2023年2月に、 現場配属型インターンシップ で現在の所属チームであるOffensive Securityプロジェクトに業務体験として参加しました。2週間のインターンシップの中で、GitHub Actionsのセルフホスト型エージェントをC2として利用する新たな脅威のPoC（Proof of Concept：概念実証）コードを開発し、その実現可能性の検証を行いました。 その後、2024年度にNTTドコモビジネス（旧NTTコミュニケーションズ）に入社し、2024年9月頃から「GitHub Actions C2をレッドチームフレームワークに発展させる」という取り組みを開始しました。このプロジェクトは、元のGitHub Actions C2のアイデアを考案した先輩社員である久保さんと2名体制で進めました。 インターンシップ参加時にもブログ記事を書かせていただいたため、詳細は以下の記事をご覧ください。 インターンシップ生があるSaaSを用いた未知のC2脅威を実証してみた - NTT docomo Business Engineers’ Blog 本記事の目的と概要 本記事では、PoCから実用的なフレームワークへ発展させた取り組みの流れと、CI/CDを攻撃基盤とする新たなレッドチームフレームワークのコンセプトについて紹介します。また、国際カンファレンスでの発表を通じて得た経験や知見について紹介します。 Offensive Securityプロジェクトの紹介 Offensive Securityプロジェクトでは、攻撃者視点のセキュリティ（Offensive Security）を専門とするチームとして、攻撃技術の調査・開発・検証に取り組んでいます。攻撃者に先んじて新たな攻撃技術を検証することで、将来の脅威を見越した防御の強化につなげています。 主な業務内容として、NTTドコモビジネスの WideAngleプロフェッショナルサービス における攻撃技術の検証支援や、最先端の攻撃技術に関する応用的な研究開発を行っており、成果のカンファレンス発表など対外的な活動にも積極的に取り組んでいます。 取り組みの着想とコンセプト インターンシップ時点のアイデア 2023年のインターンシップでは、「GitHub Actionsのセルフホスト型エージェントの仕組みを利用してC2（Command and Control）を成立させられるか」というテーマで、「GitHub Actions C2」と名付けたテクニックの概念実証（PoC）の開発と実現可能性の検証を行いました。 GitHub Actionsとは、GitHubが提供するCI/CD（継続的インテグレーション/継続的デリバリー）プラットフォームであり、開発者がコードのビルド、テスト、デプロイなどのワークフローを自動化するために使用されます。GitHub Actionsのセルフホスト型エージェントとは、「 self-hosted runners 」と呼ばれるもので、ユーザが管理するVMをワークフローの実行環境として利用できる仕組みです。 インターンシップ期間中は、このセルフホスト型エージェントを利用したC2が成立するかという仮説を確かめるために、PythonでCLIツールを実装し、シェルコマンドの実行やファイルの送受信など基本機能をPoCとして用意しました。 また、攻撃者が実際に悪用可能であるか、という観点でいくつかの制約や現実的な論点も検証しました。 具体的には、企業環境で一般的な認証プロキシ配下での通信可否や、永続化の成立可否、発生する通信などです。結果として、C2通信が十分成立しうることを確認できましたが、あくまで「脅威となりうるか」という点での検証にとどめていました。 GitHub ActionsのCI/CD機能を攻撃基盤として活用する インターンシップ時点でのGitHub Actions C2のアイデアを出発点に、「CI/CDを攻撃基盤としてレッドチームオペレーションの運用ができるか」という観点で再整理し、PoCを実用的なレッドチーム向けフレームワークへ発展させることを目指しました。 具体的には、レッドチームオペレータがGitHub上にリポジトリを用意し、ターゲット環境に設置したセルフホスト型のランナーを実行基盤として利用することで、 リポジトリで定義したワークフローをC2サーバーの役割を果たす機能として扱う セルフホスト型のランナーをC2エージェントとして扱い、実行結果をGitHub上に集約する GitHubのWeb UIや別途開発したCLIツールをワークフロー呼び出しやデータの送受信を行うC2クライアントとして利用する という構成を前提にしています。 このモデルをベースに、GitHub ActionsのCI/CD機能を攻撃基盤として活用し、レッドチーム演習をより効率的かつ再現性高く実施するための新たなフレームワーク「GHARF」のコンセプトを構築しました。 また、このCI/CDのビルド・デリバリーといった仕組みをRed Teamオペレーションに応用するアプローチをCAI/CAD (Continuous Attack Integration / Continuous Attack Delivery)と呼んでいます。 CAI/CADの構成図 「GHARF」の技術解説 GHARF (GitHub Actions RedTeam Framework)の概要 GHARFとは、GitHub ActionsのCI/CD機能を攻撃基盤として利用するレッドチームフレームワークであり、レッドチーム演習における擬似攻撃オペレータがGitHubリポジトリとセルフホスト型エージェントを活用し、ターゲット環境での攻撃活動を行うためのツールセットです。 GHARFとGHARFのスターターリポジトリは現在GitHubでOSSとして公開しているので、ご興味のある方は以下のリンクからご覧ください。 GHARF： https://github.com/nttcom/gharf GHARFのスターターリポジトリ： https://github.com/nttcom/gharf-workflows 特徴と機能 レッドチームオペレーションの完全な自動化 攻撃開発から準備・実行まで、レッドチーム演習の全工程を自動化できます。これにより、シナリオ開発に集中でき、各フェーズの結果をパイプラインとしてシームレスに連携することが可能です。 Red Team Operations as Code 攻撃オペレーションをワークフローとして構造化し、記述できます。ドキュメントの準備や繰り返し実行、バージョン管理、環境間の移植も容易に行うことができます。 リソースレス ランナーアプリケーションをC2エージェントとして活用し、C2サーバーやビルド環境を新たに構築する必要がなくなります。GitHubリポジトリやランナーで攻撃ツールのビルドや結果分析も可能です。 簡単かつ迅速なセットアップ GitHubアカウントを作成し、リポジトリをセットアップし、ターゲット環境でRunnerアプリを実行するだけで、すぐに始められるようになっています。 アーキテクチャ 全体としては以下のような構成になっています。 GHARFのアーキテクチャ CLIクライアント GHARFによる攻撃オペレーションのトリガーや制御を行うためのコマンドラインインターフェースです。ワークフローファイルの実行、結果の取得、インタラクティブなコマンド実行などをこのクライアントを通じて実行できます。 GHARFのインタラクティブCLIクライアント GHARFスターターリポジトリ GHARFを動かすために必要なプログラムとワークフロー、設定ファイルで構成される最小限の実装が含まれているリポジトリです。ユーザはこのリポジトリをクローンしてカスタマイズし、独自の攻撃オペレーションの管理を行うリポジトリを作成できます。 また、オペレータが利用するクライアントは前述のCLIクライアントだけでなく、GitHubのWebインターフェイスを用いたクライアントも利用できます。これはWorkflow Dispatch（マニュアル実行）を利用したワークフローとして実装しており、以下のようにWebブラウザの画面から別の攻撃オペレーションのワークフローの実行を連鎖的にトリガーできます。 GitHub ActionsのWebインターフェイスを用いたクライアント 倫理的配慮について オフェンシブセキュリティに基づいて攻撃技術をベースとするツールをOSSとして公開する場合は、悪意を持った第三者に悪用されるリスクがつきまといます。今回のGHARFの開発にあたって、以下のような倫理的配慮にもとづく設計・準備を行いました。 Responsible Disclosure 今回開発したGHARFのベースとなったGitHub Actions C2の手法については、GitHubに事前に開示し、許可を得た上で発表しています。（過去にBSides LVやDEF CON Cloud Village, AppSec Villageで発表した際にDisclosureを行いました） ユーザ同意プロセス ユーザの意図に反して不正なアクションや予期しない操作が実行されることを防ぐため、デフォルトの設定で実行端末における承認プロセスが必須となるような実装をしています。 アーティファクトのトレーサビリティ ワークフローによって生成されるアーティファクト（バイナリプログラムなど）に侵害指標（IoC）を埋め込むメカニズムを実装しています。また、これらのアーティファクトを検出するためのYARAルール 1 も公開しています。 セキュリティポリシー 万が一ツールの悪用が確認された際に、迅速に報告を受け取れるようにするための連絡窓口を用意しています。また、詳細なセキュリティポリシーはGitHubリポジトリにて公開しています。 世界の舞台での登壇 GHARFの取り組みについて国際カンファレンスで発表することを目標にし、CODE BLUE 2025 BlueboxとBlack Hat Europe 2025 Arsenalに応募しました。結果としては、両者ともに採択されることができました。特に海外の場で発表を行ったBlack Hat Europeでの経験にフォーカスして紹介します。 登壇したカンファレンス CODE BLUE / Black Hat Europe CODE BLUEとは？ CODE BLUEとは、日本発の国際的なサイバーセキュリティカンファレンスです。毎年東京で開催されており、国内で開催されるものの中では最大規模のセキュリティカンファレンスです。 CODE BLUEは主に以下の項目で構成されています。 メイントラック：カンファレンスの中心となるセッションで、最新の研究成果や技術動向を講演形式で発表します。 Open Talks：カンファレンスのスポンサーによる講演セッションで、最新のセキュリティ技術や製品に関する情報を講演形式で発表します。 U25: 25歳以下の若手研究者やエンジニアによる講演セッションで、若手の視点から最新の研究成果や技術動向を講演形式で発表します。 Bluebox：オープンソースのツールやプロジェクトを紹介する場で、デモを交えて講演形式で発表します。 ワークショップ：セキュリティに関するさまざまなテーマについて、実践的な内容を学ぶことができるセッションで、ハンズオン形式で行われます。 トレーニング：専門家によるセキュリティに関するさまざまなトレーニングが行われます。 公式サイト： https://codeblue.jp/ Black Hat Europeとは？ Black Hatとは、世界最大級のサイバーセキュリティカンファレンスのシリーズです。毎年アメリカ、アジア、ヨーロッパ、中東の4地域で開催されており、今回参加したのはロンドンで開催されるBlack Hat Europeになります。 Black Hat は主に以下の4つの項目で構成されています。 Training：専門家によるセキュリティに関するさまざまなトレーニングが行われます。テーマはユニークなものも多く、モダンなセキュリティ技術を学ぶことができます。通常2-4日間の期間で、カンファレンスの会期の前に開催されます。 Briefings：最新の研究成果を講演形式で発表するメインセッションです。各セッションは40分で構成され、セキュリティの幅広い分野のトピックが扱われます。 Arsenal：最新のセキュリティツールをデモを交えて発表する場です。発表はブース形式で行われ、議論を通じて発表者と聴講者が直接交流できる場です。ビジネスの目的で発表することは禁じられている点が特徴です。 Business Hall：セキュリティ関連企業が自社の製品やサービスを展示する場です。 公式サイト： https://blackhat.com/eu-25/ 今回のBlack Hat Europe 2025では、115か国から約7,000人が参加し、うち日本からは約50人が参加していました。 発表内容 今回はGHARFというツール開発の成果を発表することを目的としていたため、CFP（Call for Papers）の申し込み時期を踏まえ、CODE BLUEのBlueboxとBlack Hat EuropeのArsenalという2つのカンファレンスに投稿しました。 発表内容はいずれもほとんど同じで、GHARFのコンセプトや特徴、攻撃オペレーションの流れ、デモ動画などを紹介しました。 ロンドンでのデモ発表とその反応 Black Hat Europe 2025はExCeL Londonというカンファレンスホールで開催されました。我々の発表スケジュールはカンファレンス会期2日間のうち初日の午前最初のセッションで、80分の枠の中で3回のデモ発表を実施するという形式で行いました。合計で約60人の聴講者に参加していただき、そのうち6人ほどと口頭で議論を交わしました。 CODE BLUEとBlack Hat Europeの発表で大きく異なる部分としては、CODE BLUEでは講演ルームで日本語で発表するという形式であったのに対し、Black Hat Europeではブース形式で英語で発表するという部分でした。 英語に不慣れである筆者にとってかなり苦労した部分でしたが、なるべくスライドやデモ動画に多くの情報を載せつつ事前に発表スクリプトを用意することで、なんとか発表を行うことができました。質疑応答に関しては、Q&Aを送信できるWebフォームを用意し、音声でのコミュニケーションが厳しそうな場合はQRコードでフォームに誘導するということも準備しました。 他の難しかった点として、ブース形式であるため会場内が騒々しく、マイクの音声が届きづらいという点がありました。 現地での実際の聴講者からの反応としては、機能に関する質問の他に、どの程度利用範囲の拡張ができるかといった質問や、好意的なコメントなどをいただきました。 具体的にいただいた質問・コメントの例としては、以下のようなものがありました。 機能に関する質問 攻撃ツールはどのように実行されるのか？メモリにロードされるか？ AV/EDR 2 に検知されるのか？ 利用範囲の拡張に関する質問 Webアプリのペネトレーションテストでは利用できる？ Kubernetes（k8s）やGoogle Cloudなどは対象にできる？ コメント 面白かった。ツールを触ってみる。 個別にデモをしてもらうことはできる？ 回答としては、攻撃ツールは主にファイルベースで扱われる、検知回避はこのツールのフォーカス外である、利用範囲の拡張については現時点では限定的であるといったことを回答しました。 余談になりますが、ロンドンへの出張の中で一番苦労した部分は「移動と時差ボケ」でした。羽田～ロンドン間のフライトで約15時間かかり、その後ロンドンのヒースロー空港から会場までの間も車で約2時間かかるという長時間の移動で、大変疲れました。また、幸い発表時間は現地の午前中だったため問題なく済ませることができましたが、日本との時差が9時間あり、午後の講演は眠気と闘いながら聴講することになりました。 Black Hat Europe会場内の看板 Arsenal会場で発表している様子 おわりに 今回の取り組みを通じて、GitHub Actionsを攻撃基盤として利用するというアイデアを、単なるPoCから実用的なレッドチームフレームワークへと発展させ、最終的にはBlack Hat Europe 2025のArsenalで発表するという目標を達成できました。また、ツール開発と海外カンファレンスでの発表経験は非常に貴重な経験となりました。 インターンシップ参加時の記事で以下のように書かれているように「この取り組みの発展的な内容を国内外のカンファレンスで発表するかもしれない」という話は聞いており、当時はその足掛かりの部分で貢献できたのであればよかったなという程度の気持ちを抱いていました。 ※今回注目したあるSaaSに関する発展的な攻撃テクニック(本記事記載のC2への応用を含む)について、NTTコミュニケーションズ RedTeamとして国内外のカンファレンスへ投稿する予定です。そのため、本記事では具体的なSaaS名の記載を控えます。 入社後にインターンシップで行った技術検証の続きに取り組まないかとお誘いをいただき、2年半越しに海外登壇まで達成するということを経験できたことには感慨深いものがありました。 また、入社2年目でこのような大きな挑戦をすることができたのは今回の取り組みをリードしていただいた久保さんと、Offensive Securityプロジェクトのメンバーの方々、そしてアドバイスをいただいたNTTセキュリティジャパンのメンバーの方々の多大なるサポートのおかげであると感じています。 今回の取り組みを通じて得た経験や知見を活かして、今後も攻撃技術の調査・開発・検証に取り組んでいきたいと思います。 マルウェア分析や脅威ハンティングに向けて設計された、オープンソースのルールベースパターンマッチングツール「YARA」で利用されるマッチングルール。 ↩ Antivirus / Endpoint Detection and Response。 ↩

はじめまして！ バリューチェーン本部の花ヶ崎雄太と申します。 新卒1年目の12月に一般社団法人コンピュータ教育振興協会（ACSP）の主催する3次元CAD利用者技術試験の準1級を受験し、合格いたしました。 今回はそれについて、 ・3次元CAD試験とは ・受験の理由と感想 ・出題される問題の概要と傾向 ・実際の学習方法 ・合格のコツ の5つに分けてご紹介します。 本記事の想定読者 ・3次元CAD利用者技術試験に興味がある/取得の予定があるが、CADの操作については未習得な人 ・仕事や学業で製造系の業界や学問に携わっており、これからCADを習得予定の人 ※なお本記事では「CADそのもの」やそれに関連した個別の用語についての説明は行いませんが、想定読者向けに難しいと考えられる単語には一部注釈をつけています。 1. 3次元CAD試験とは 試験概要 ここは公式から引用します。 『「3次元CAD利用技術者試験」は、3次元CAD を利用するエンジニアや学生が身につけておくべき知識と技能が証明できる、3次元CAD試験制度です。』 『3次元CADシステムを利用した機械系・製造系のモデリング・設計・製図などの業務に従事することを目指す方、もしくは従事して間もない方を想定して試験を行います。3次元CADを学び、知識と操作の基礎的な部分を習得し、設計の補助業務やオペレーターを目指す方が対象です。』 2025年度 3次元CAD利用技術者試験 概要 より引用。 つまり3次元CADをこれから積極的に利用していこう、という方に向けての試験ということですね。 ちなみに本試験は製造業でCADを使用する方向けであり、建築業向けではないようです。 2級について　～準1級受験には事前に2級の取得が必要～ 準1級を受験するためには事前に2級に合格している必要があります。 具体的には準1級の申し込み期限の前日（準1級試験日の1か月ほど前）までには2級を取得している必要があるので、準1級以上の取得を目指す方はまずは2級を取得しましょう。 2級は比較的難易度の低い選択式の試験で、CBT形式でテストセンターで実施されます。 難易度は高くはありませんので、公式の販売している書籍（ https://www.acsp.jp/ACSP_books.html ）を学習して過去問演習を重ねれば十分合格可能です。 私の累計の学習時間は 15時間 ほどです。 2級を学習することで、その後のモデリングでも用いる基本的な用語や手法を知ることができます。 2級にはモデリングの実技はありませんが、できれば２級もCADを触りながら学習したほうが学習効率が高いと思います。 準1級について 準1級は年に2回、例年7月と12月に開催されます。 いつでも受けられる2級とは違い年2回のみの開催ですので、機会を逃さないように注意しましょう。 準1級では実際に会場にPCを持ち込み、モデリングの実技を行います。 詳しくは後述しますが、問題は2次元図面を読み取って パーツモデル*1 を作成する形式です。 そうして作成したモデルの体積、表面積などを測定し、解答群の中から最も近い値をマークシートに記入する形式で試験が行われています。 試験時間は120分と長めです。 ーーーーー *1 パーツモデル ：単一の部品を3DCADで作成したモデルのこと。 ーーーーー 2. 受験の理由と感想 なぜ受験したのか？ 率直に言えば、業務上必要だったからです。 私の所属する部署はCADをメインの商材として扱っており、CADの基礎知識/技術を身に着ける必要があります。 そのため業務上の要求として最低限「2級」の資格を取得することとなっていました。 しかしOJTの方からのアドバイスや、より高みを目指したいという思いから、私は準1級に挑戦することにしました。結果的に、私の所属するバリューチェーン本部の新人14人のうち、準1級を取得したのは私含め2人でした。 受験してよかったか？ 結論としては、よかったです。そう思う観点は3つあります。 1．CADの基礎知識および基本的なコマンドを習得することができた。 準1級では、要求されるコマンドは基本的なものがほとんどです。試験問題がスムーズに解けるようになる頃には、基本的な形状（例えばテレビリモコンなど）なら難なくモデリングできるくらいのスキルが十分につきます。 2．扱うCADに関する理解が大きく深まった。 学習・受験に利用するのはそれぞれの受験者が利用しているCADですから、そのCADについての設定や効率的な使用方法、得意や苦手などの理解が大きく深まります。 今回私は「NX」というCADを使って学習と受験を行いましたが、学習の過程でNXならではの強みや特異な点を複数感じ、理解することができました。 3．単純に楽しかった。 個人的には重要な観点だと思います。 CADで形状を作るのが、なんだか砂山で城を作っているような感覚で楽しかったです。 またモデリングの時間が早まることや、それまで気づかなかったモデリング方法に気づくことなどで自分の成長をひしひしと感じられます。 今回の学習と受験経験を通して、仕事を行うモチベーションという点で「楽しい」という感覚が重要だと実感できました。 3. 出題される問題の概要と傾向 ここでは準1級における具体的な問題の概要と傾向、主な使用コマンドについて紹介します。 問題の概要 準1級では、 準1級と1級で共通の問題が2問 と、 準1級のみの問題が1問 の、 合計3問 出題されます。 どの問題にも共通なのが、最終的な問題の解答は「モデルの完成」ではなく、「 完成したモデルからのパラメータの測定値 」であることです。 具体的には各問題につき3～5問の設問があり、「点Aから点Bの長さを測定し、選択肢から最も近いものを選べ」「立体Cの体積を測定し、選択肢から最も近いものを選べ」といった出題がなされます。 指示や図面に従ってモデリングをし、その最中や完成後にパラメータの測定を行い、マークシートに記入する、までが、基本的な解答の流れです。 (1) 共通問題-1 座標や形状、モデリング方法についての指示があり、指示通りにモデリングを行う形式です。 基本は指示に従えばよいので、練習を繰り返すことでコマンドを理解し、モデリング速度を上げることが重要です。 主な要求コマンド スケッチ、押し出し（和・差・積）、回転、直方体、円筒、球、エッジブレンド、面取り、シェル、データム平面（無限平面）、トリムボディ、ミラージオメトリ、パターンジオメトリ、線 ※コマンドの名称はNX準拠のため、CADによって異なる可能性があります。 (2) 共通問題-2 3面図*2 を読み取って、その図面の通りにモデリングを行います。 無限平面*3 を使った複雑な押し出しが求められることが多く、効率よく解くためには、経験に基づく「閃き」が必要です。個人的には準1級範囲で最も癖が強いと感じています。 また実際の現場で作ることは決して多くない形状だと思いますので、問題に慣れるまで時間がかかります。 主な要求コマンド スケッチ、押し出し（和・差）、直方体、エッジブレンド、面取り、データム平面（無限平面）、トリムボディ、円錐、点セット ※コマンドの名称はNX準拠のため、CADによって異なる可能性があります。 ーーーーー *2 3面図 ：正面図、側面図、上面図の3種の図面。3次元形状を3方向から投影した2次元図面であり、この3つを見ることで3次元形状の作成が可能。 *3 無限平面 ：CADではXYZ平面以外にも任意の平面が作成可能。この平面で立体を切断する手順は超頻出。 ーーーーー (3) 準1級問題 共通問題-2と同じく、3面図を読み取ってその通りにモデリングを行います。しかしこちらの方が”現実にありそうな”形状が出題されるので、比較的イメージはつきやすいです。 ただ複雑なスケッチやコマンドの使用をせざるを得ない場合もあり、要求されるモデリング力は高いです。 主な要求コマンド スケッチ、押し出し（和・差）、回転、直方体、円筒、エッジブレンド、面取り、シェル、ドラフト、データム平面（無限平面）、トリムボディ、点セット ※コマンドの名称はNX準拠のため、CADによって異なる可能性があります。 4. 実際の学習方法 コマンドを知る 私はまず、コマンドを知ることから学習を開始しました。 最初はそもそも必要なコマンドがバーのどこにあるのか、似たようなコマンド（例えば、パターンフィーチャとパターンジオメトリ）のうちどれを使えばいいのかなど、全くわかりません。 そこで最初は、準1級の共通問題-1をじっっっくり時間をかけて解き、「どのコマンドがどこにあるのか」「どのコマンドをどの順番で使えば目的の形状を実現できるのか」を学習しましょう。 共通問題-1は問題文の中で使うコマンドや座標を指示してくれているので、「コマンドの所在の把握」や「そのコマンドで何が起こるのか」の学習に向いています。 ちなみに私は最初、共通問題-1を1問解くのに4時間かかりました（笑）。 とにかく演習あるのみ コマンドについてある程度把握出来たら、あとはとにかく問題を解きまくります。 問題は基本的には過去問です。 公式の書籍には過去問が1年分（前期と後期の2回分）掲載されているので、演習に使用できます。 また 試験の公式サイト （ https://www.acsp.jp/cad/3d_past_web3d.html ）では、過去問において出題された形状のモデリング結果が掲載されています。図面から正解の形状が想像もつかないときや、行き詰まった際に参照するととても役立ちます。 さらに、 日経クロステック （ https://xtech.nikkei.com/dm/article/COLUMN/20120605/221476/ ）では当試験の例題が複数掲載されているので、そちらを利用して演習するのもよいでしょう。 問題に取り組む順番は 共通問題-1：～15分で解けるようになるまで 準1級問題：～60分で解けるようになるまで 共通問題-2：40～60分で解けるようになるまで をおすすめします。 共通問題-2と準1級問題は図面の読み取り力も必要になりますが、共通問題-2では図面で隠された部分（点線部分）に三角形の入れ子構造を作ることが要求されます。しかしコレには非常に癖があり、図面に慣れていない状態でいきなりやるのは難しいです。 そのため、手順が多い代わりに比較的オーソドックスな準1級問題で実力をつけてから取り組むのがおすすめです。 合格までの累計学習時間は？ 私の場合は合計 70時間 ほどです。 業務時間での学習が認められていたため、平均1日2～3時間の学習を約1.5か月継続しました。 ただCAD経験ゼロの状態から開始し、初期はコマンドの学習に丸1日費やすこともありましたから、CAD使用経験が少しでもあるならこの時間は短くなると思います。 5. 合格のコツ 最後に私の経験から役立ったと感じた具体的な合格へのコツを、いくつかかいつまんでご紹介します。 準1級受験用のコマンドバーを作る CADによって異なるとは思いますが、私の利用するNXではコマンドのバーをカスタムで作成することができたので、試験で使うコマンドを集めてカスタムバーを作成して使っていました。 コレがあるだけでいちいちコマンドを探す手間が省け、また慣れも早かったので解答の高速化が実現しました。 また副次的に「カスタムバーを作成する」という設定面での学習ができたのも良かったと感じました。 同一形状を作るうえでも、複数の実現方法があると知る 単なる円筒を作成するうえでも、 ・円をスケッチして押し出し ・長方形をスケッチして回転 ・円筒コマンドの利用 など 複数の実現方法 があります。 これが試験問題ともなると、各形状を実現する方法が非常に多岐にわたります。 その中でどの方法が自分に合っているのか、どの方法が効率がよいか、といった部分は、問題を解くうちに経験的に身についてきます。 例えば上の例であれば基本的には「円筒コマンドの利用」が最速でしょう。 たくさん演習問題を解いて、自分に合ったモデリング方法を学びましょう。 またその方法が実際の業務や研究で使用するものならなお良いですね。 設問の順番通りにモデリングを行う 上の事項に関連して、同一形状を作るうえでも色々な順番で実現することが可能です。 しかし「試験の合格」を意識する場合は、設問の順番通りにモデリングを行うことをおすすめします。 指示がある共通問題-1は当然として、共通問題-2、準1級問題にも効率の良いモデリング順が存在します。これは設問の順番に従えば実現できるようになっています。 例えば 設問(1)：点Aと点Bの距離を測定 設問(2)：面Cの面積を測定 の場合、面Cを作る過程で、点Aと点Bも完成していることが多いです。 そしてここで先に、 設問(2)の面Cのところまで作った後に設問(1)を解いて間違っていた場合、まず間違いなく設問(2)も間違っているので、面Cのところまで作り直しになってしまいます。 しかし先に設問(1)の点Aと点Bを作成し解答しておけば、 間違っていても早く気づくことができる*4 のです。 ーーーーー *4 間違っていても早く気づくことができる ：モデリング結果が違うときには「測定結果」が「解答の選択肢」と大幅に異なることが多いため、モデリングのミスには比較的気づきやすいです。 ーーーーー まとめ 今回は、3次元CAD利用者技術試験の準1級の受験や学習について、新卒1年目の目線で解説しました。 学習コストは大きいですが、準1級に合格する程度の知識/技術があれば、基本的なモデリング能力を身に着けたと十分言っていいくらいのスキルは得られます。 また単に学習するだけでなく、その中で実際の設計に活かせる経験も手に入ったと思います。 今後はさらにモデリング力を高めるために1級の取得を目指します。１級はアセンブリの知識やさらなるモデリングの高速化が求められるため、引き続き経験を積んでスキルアップを志向します。 私たちは一緒に働いてくれる仲間を募集しています！ 電通総研 キャリア採用サイト 電通総研 新卒採用サイト 執筆： @hanagasaki.yuta レビュー： @yamashita.tsuyoshi （ Shodo で執筆されました ）

こんにちは。Drawer Growth グループの江良です。 キャディが「製造業 AI データプラットフォーム」の構想を打ち出してから半年ほどが経ちました。 caddi.com このコンセプトの実現にあたっては、「AI」の部分だけでなく、「データ」の部分を支える仕組みづくりも重要になってきます。今回は、私が携わっているプロジェクトで導入した Apache Iceberg とその使いどころについて紹介したいと思います。 製造業におけるデータ活用の難しさ 本題に入る前に、まずは背景について少し補足します。 （Iceberg の話だけを読みたい人は「採用したアーキテクチャ」のところまでスキップしてください。） モノづくり産業における会社には多種多様なデータが存在する 製造業の世界で登場するデータにはさまざまなものがあります。 詳しくは キャディ、製造業AIデータプラットフォームとしての、第二章。｜加藤/キャディCEO でも紹介されていますが、具体例を挙げると以下の通りです。 分類 具体例 構造化データ ・実績データ（見積実績、受注実績、発注実績、製造実績、検査実績、出荷実績、請求実績、在庫実績など） ・マスタデータ（顧客情報、製品、仕入れ先、工程、設備情報、検査器具、チャージなど） 半構造化データ ・CAD 非構造化データ ・図面 ・写真 ・文書（仕様書、不具合報告書、議事録など） （会社の規模にもよりますが）少なくとも十数種類 〜 百数種類のデータが企業内に存在することがイメージできるかなと思います。 当然ながら、それぞれのデータのスキーマは異なります。データのサイズや更新頻度も様々です。実績データに関しては、一億件近くの規模のデータが存在するケースもあります。 データのフォーマットは会社ごとに異なる 図面は、書き手の意図を確実に読み手に伝達するため、JIS 規格に基づいて標準化されています。一方で、表題欄と呼ばれる図面のメタデータ（図面番号、尺度、部品名称、設計者名、承認者名、使用する材質など）を記載する欄の様式は各社が自由に設定できます。 CAD に関しても、どのソフトウェアを使用しているかは各社でバラバラです。 実績データやマスタデータの管理方法は当然各社で異なります。PLM/PDM や ERP といったソフトウェアで管理されていることが多いですが、製造業全体で「標準」と言えるような規格はありません。 データの「活用」に向けたハードル こういった多種多様なデータを活用するためには、まず、非構造化データや半構造化データをなんらかの方法で構造化する必要があります。その上で、データ同士をなんらかの方法で紐づけて、データ同士の連関がわかるようにする必要があります。 データのフォーマットは会社ごとに異なり、さまざまなバリエーションがあります。そのため、「データ同士がどうすれば紐づくか」も一意には決まりません。 ここまでの話をまとめると、 さまざまなスキーマのデータを柔軟に取り扱うことができ、 データ同士をどのカラムで紐づけるべきかを柔軟に選択でき、 大規模なデータセットを取り扱える こういった要件を満たすことが、製造業におけるデータの「活用」を実現する上では求められます（製造業に限った話ではないかもしれませんが）。 データを活用するための一般的な解決策 さて、ここまで説明してきたような課題を解決するためにはどうすればいいでしょうか？一般的には、データエンジニアリングによるアプローチが考えられるかなと思います。 三行くらいで簡単にまとめるとこんな感じ。 データエンジニアリングを専門とするチームを組成し、 データレイクに生データを集め、 ETL パイプライン等を通じてデータを活用可能にする Snowflake 等の登場により、企業がデータ分析を始める際のハードルは大きく下がってきている印象があります。しかしながら、こうしたことを実現するためには、依然としてデータエンジニアリングを専門とするエンジニアが手を動かす必要があります。 改めて、先ほどまとめた課題を再掲します。 さまざまなスキーマのデータを柔軟に取り扱うことができ、 データ同士をどのカラムで紐づけるべきかを柔軟に選択でき、 大規模なデータセットを取り扱える （加えて、製造業に特有のユースケースに特化した機能を提供できる） 上記のような機能を SaaS として提供することで、データをよりかんたんに活用できる状態にしたい、そのための方法を考えてほしい、というのが、ぼくの所属するチームのここ半年のミッションでした。 データレイクハウスの登場 先ほど、データを活用するための一般的な解決策としてデータレイクについて触れました。大規模なデータセットを活用していく上で、データレイクのアーキテクチャは有効ですが、一方で課題もあります。 代表的な課題としては、データの一貫性に関する課題があります。データはあくまで GCS 等のストレージに配置されているだけの状態にあるため、RDBMS でいうところのトランザクションのような概念はありません。そのため、複数のプロセスから同時に書き込みをするとデータが壊れてしまう可能がありますし、中途半端に書き込みがされた状態のデータが予期せず参照されてしまう可能性もあります。 こうした課題から、近年、データレイクハウスと呼ばれるアーキテクチャが注目されてきています。 データレイクハウスアーキテクチャは、データを保存するストレージのレイヤと、データに対して SQL を実行するクエリのレイヤを分離し、その間にメタデータのレイヤを設けているのが大きな特徴です。メタデータのレイヤを設けることで、ストレージ上のデータをテーブルであるかのように抽象化したり、ACID トランザクションを実現したりすることができます。 www.databricks.com それぞれのレイヤで採用できる代表的なツールは以下の通りです。 メタデータのレイヤでは、Open Table Format と呼ばれる仕様に従ってデータが管理されます。この仕様に従ってデータを保存することで、トランザクションなどの便利な機能が使えるほか、クエリのレイヤでどのツールを使うか（Spark、Hive、Flink、Trino など）がユースケースに応じて選択可能になります。 採用したアーキテクチャ 前置きが長くなりました。キャディでの Iceberg の使いどころについての話に移ります。 キャディでは、CADDi Drawer が扱うデータのうち、構造化データを扱うサービスにて Iceberg を使用しています。構造化データのうち、特に実績にまつわるデータはレコード件数が多い傾向にあります。スキーマが不定だったり、紐付け項目が一意に定まらなかったりするという特徴も相まって、RDBMS を素朴に利用してアプリケーションを設計すると、中長期的に期待するパフォーマンスが出せないのではないか、という懸念がありました。 一方で、データの更新頻度は少なく、データの追加操作がメインのユースケースであることから、「RDBMS 以外の選択肢は本当にないのか？」を検討し、紆余曲折を経て Iceberg に辿り着きました。 各レイヤで何を採用したか 先ほど、データレイクハウスアーキテクチャはクエリ、メタデータ、ストレージの 3 つのレイヤで構成される、ということについて説明しました。それぞれのレイヤで採用できるツールにはいくつか選択肢がありますが、CADDi Drawer では Trino、Iceberg、GCS（Google Cloud Storage）を採用しました。 Open Table Format が掲げるテーマとして代表的なものに「バッチとストリーミングの統合」があります。ストリーミングのユースケースを満たすなら、Apache Spark を採用し、Structured Streaming 機能を活用するといった選択肢も考えられます。 iceberg.apache.org ですが、SQL のインタフェースを通じてデータをクエリできれば十分であり、検討時点ではストリーミングのユースケースが見当たらなかったため、比較的導入コストの小さい Trino を採用しています。（リリースまでのスケジュールが非常にタイトであったこと、今回ユーザに提供する機能はあくまでベータ版であったこと、といった事情もあったりします。） Iceberg に関しては AWS など BigTech 各社が力を入れていることから興味を持ち、採用を決めました。 データレイヤーに関しては、キャディでは Google Cloud を全面的に採用していることから GCS を採用することに決めました。 「ベータ版としての提供なのであれば BigQuery でもいいのでは…？」という考えも頭をよぎりましたが、不特定多数のユーザーに BigQuery を用いた機能を解放するとクエリコストのコントロールが難しくなりそうなため、候補からは外しました。 アーキテクチャの詳細 アーキテクチャ図は以下の通りです。 構造化データを扱うマイクロサービスは、キャディの中では珍しく Java を採用しています。静的型付けのある言語で開発したかったのと、Trino や Iceberg などのライブラリとの親和性の高さから採用を決めています。 処理の大まかな流れは以下の通りです。 ユーザがアップロードした CSV をパースして Iceberg に保存する 図面の解析結果を一定間隔のバッチで受け取り Iceberg に保存する Iceberg のデータを用いてデータの紐付けを解決し、「図面に紐づく構造化データ」を UI に表示できるようにする 緑色の線が「ユーザが CSV をアップロードしてから Iceberg に登録されるまで」の流れを表し、赤色の線が「図面の解析結果が Iceberg に登録されるまで」の流れを表しています。別のジョブを通じてデータ同士の紐付けを解決して Iceberg に書き戻し、この「解決済み」のデータを REST API から返却して、ユーザ向けの画面に表示しています。 Trino は GKE クラスタ上に用意した専用のノードにデプロイして稼働させています。コーディネータがクエリを受信し、実行計画を立てて、ワーカに対して指示を送ります。ワーカはコーディネータからタスクを受け取り、データを実際に処理します。 Iceberg Catalog としては Databricks 社の iceberg-rest-image を利用しており、こちらも GKE クラスタ上にデプロイして稼働させています。カタログの情報は AlloyDB に永続化し、ファイルの実態は GCS に保存しています。 github.com Iceberg Catalog にも選択肢がいくつかあります。詳しく知りたい方は下記の記事を参照ください。 bering.hatenadiary.com 大量のデータの INSERT 操作は、パフォーマンスの観点から Iceberg Java API を通じて実施しています。 iceberg.apache.org 所感 Iceberg および Trino を採用したことにより、 テナントごとに異なる、さまざまなスキーマのデータを柔軟に取り扱うことができる データ同士をどのカラムで紐づけるべきかを柔軟に選択できる 大規模なデータセットを取り扱える といった、当初目的としていたアーキテクチャ特性を満たすサービスを構築できました。 データの書き込み性能のスループットに関しては、1000 万件規模のデータの登録が 15min 程度で完了し、読み込み性能に関しても一般的な Web アプリケーションとして違和感のないレスポンスタイムで安定して結果を返すことを確認できました。 今後の課題 ここまで、Iceberg 導入の背景と使いどころについて説明してきました。 直近のゴールは達成できたものの、今後取り組みたいこと、改善したいポイントはたくさんあります。 全社を横断したプラットフォームへの進化 Iceberg を使った仕組みは、現在、あくまで CADDi Drawer の中の一機能という立ち位置です。将来的には CADDi Drawer のデータだけではなくCADDi Quote のデータも横断して取り扱えるよう、アプリケーションとプラットフォームに分割し、アプリケーションを横断して利用できるようにしていく必要があります。 また、こちらのインタビューでも語られている通り、製造業 AI データプラットフォーム CADDi には、今後も新規アプリケーションを追加していくことを想定しています。 www.fastgrow.jp 「3 年で数十個」 という目標を達成する上で、Iceberg を使った基盤を全社を横断したプラットフォームに進化させていく取り組みは急務といえます。 Iceberg の機能をもっと使い倒したい Iceberg にはトランザクション管理に関する仕様が定義されています。この仕様に従って実装されたクエリエンジンを利用することで、更新データの競合が疑われる場合に該当の操作を abort し、データの一貫性を保証することができます。 現時点ではデータの追記（AppendFiles）しか利用していないため、下記の資料で解説されているような同時書き込み時における課題には直面していません。 speakerdeck.com また、Iceberg には in-place table evolution という仕様が定義されています。これはテーブルのスキーマを ALTER TABLE 文を発行して変更したり、テーブルのパーティションを行うキーを後から変更したりすることができる、という機能です。 iceberg.apache.org 現時点では、一度定義したテーブルのスキーマを変更するような機能を提供していないため、この課題には直面していませんが、早晩対応が必要になりそうな予感がしています。 また、Iceberg を全社を横断したプラットフォームに進化させていく上では、各アプリケーションのデータベースに永続化されているデータを、ストリーミング処理を通じてニアリアルタイムに連携できるようにしていく必要も出てきそうです。 やることがたくさんあって大変なわけですが、これはこれで「Iceberg の真価を発揮できるチャンスがたくさんある」と言い換えることもできそうです。 マルチテナント SaaS におけるテナント分離の課題 書籍『マルチテナント SaaS アーキテクチャの構築』でも語られている通り、SaaS を提供する事業者としては、異なるテナントのデータが誤って参照されてしまうことのないよう、テナントの分離を強制する仕組みの構築が重要となります。 CADDi Drawer では、Iceberg のスキーマをテナントごとに作成し、テナントごとのテーブルをスキーマ内に作成することでデータを物理的に分離しています。異なるテナントのデータを参照できないようにする仕組みはアプリケーションのレイヤに実装しています。 こういった仕組みはアプリケーションのレイヤだけでなく、インフラのレイヤにも導入し、多層的なテナント分離を実現したいところです。ですが、現在採用している Iceberg Catalog にはそういったアクセスコントロールに関する機能はないため、やむなく断念しています。 Apache Polaris では、RBAC モデルをベースとした柔軟なアクセスコントロールの仕組みが提供されるようです。現時点では Incubation のステータスにあるため採用を見送ったのですが、正式版がリリースされた際には載せ替えを検討しています。 polaris.apache.org Iceberg の利用を検討している方は動向をウォッチしてみると良いかもしれません。 おわりに いかがだったでしょうか。 Iceberg の採用を検討している方の参考になれば幸いです。 最後に宣伝で、キャディではエンジニアを採用しています。本記事を読んで、「製造業の AI データプラットフォーム」構想に興味を持った方、今後の課題を一緒に解決していきたいと感じた方はぜひご連絡ください。 recruit.caddi.tech