GitHub
GitHub連携で取得する
Athenara用のアプリをGitHubに登録し、対象リポジトリの中身を読む権限だけを与えます。コードが更新されるとGitHubから知らせが届き、新しい版を取り込みます。
08 — Getting started
No. 08
導入
Getting started
必要なのは、社内の1台と、
調べたいプロダクト一つ。
揃えるのは、社内に置く1台の機材、調べたいプロダクトのソースコード、そのプロダクトの起動方法を書いた設定の三つだけ。どれも一度用意すれば、日々の手入れはほとんど要りません。
- データセンターAIモデルごと机に載る1台で動き、専用ラックも要りません。
- セキュリティの専門人材方針はチャットで、ふだんの言葉で伝えれば十分です。
- 毎日指示を出す担当者次に何を確かめるかは、Athenaraが自分で決めます。
i.導入の流れと用意するもの
0
Install
機材を置く
推論に使うAIモデルも、調べるプロダクトも、調査の記録も、すべてこの1台に収まります。
設置のあと、社内のIT担当がAthenaraのセットアップを一度だけ実行します。環境の準備、AIモデルの取り込み、動作の確認までが順に進みます。AIモデルはこのとき機内に取り込まれ、以後の調査で外部のAIサービスに接続することはありません。
調査の様子を見る管理画面とチャットも、この1台が受け持ちます。いずれも1台の外へは公開しない形で動きます。
NVIDIA DGX Spark（機材の参考写真）— Photo: Daniel Lu, CC BY-SA 4.0 1
Place
対象リポジトリを置く
Manual
手動で置く
担当者が社内の1台へ直接複製して置きます。GitHubを使っていなくても始められます。その1台からリポジトリへ接続できる環境なら、更新も取り込みます。接続できなければ手元の版で調べ続け、更新できなかった理由を管理画面に表示します。
画面とAPIのように、一つのプロダクトが複数のリポジトリに分かれていても、まとめて一つの調査対象にできます。
2
Configure
起動方法を書く
Athenaraはコードを読むだけでなく、隔離した使い捨ての環境でプロダクトを実際に起動して試します。そのために、立ち上げ方を伝えておきます。
書くのは、起動コマンドと、起動したプロダクトにアクセスするURL。起動前の準備や止め方の手順があれば添えます。開発者が普段手元で使っている手順を書き写せば十分です。設定ファイルはリポジトリの中に一つ置き、管理画面からも編集できます。起動できたかどうかと、その記録も管理画面で確かめられます。
本番環境の接続先を書く欄はありません。試す相手は、その場で起動したプロダクトだけだからです。
services:このリポジトリで起動するもの- id: api名前start: docker compose up起動コマンドurl: http://api:3000起動したプロダクトの入口
設定ファイルの例（一部の行は省略）。一つのリポジトリに起動するものが複数あれば、同じ形で並べます。 3
Run
調査が始まる
管理画面で調査を始めると、そこから先はAthenaraが自律的に進めます。これまでに分かったこと、まだ確かめていない条件、コードの更新差分を見て、次に確かめる問いを一つずつ自分で決めます。夜間も休日も止まりません。
問いごとに新しい隔離環境で試し、終われば破棄します。報告に上がるのは再現できた問題だけで、手順と証拠が付きます。
以後、人の役割は二つだけ。朝、昨夜の間に確かめた範囲と結果を見ること。調べてほしい方向があれば、チャットで伝えること。
ii.自社プロダクトでの実績
Athenaraは、自社のプロダクトで
すでに業務として動いています。
調べている相手は、実際の業務で使われているシステム。デモのために用意したアプリケーションではありません。社内の1台に常駐させ、担当者が結果を見て方針を伝える。このサイトで説明している使い方を、自社でもそのまま続けています。
そのシステムで、Athenaraは外部診断では拾えなかった問題を見つけ、修正まで至っています。
外部診断は、決まった期間に決まった範囲を点検するものです。Athenaraは期間を区切りません。確かめた範囲とまだ確かめていない条件を記録し、次の問いを選び続けます。点検の後に入った変更も、差分として取り込みます。点検の網から漏れたところに届くのは、この続け方があるからです。
iii.最初の一つの選び方
全部を一度に、ではなく、
まず一つを任せてみる。
社内に複数のプロダクトがあっても、最初から全部を対象にする必要はありません。一つを任せ、朝に届く結果を何週か読んでみれば、自社のコードに対して何が分かるのかを、自分たちの目で判断できます。
以下の問いに、すべて当てはまる必要はありません。当てはまる問いが多いほど、最初の一つとして違いが見えやすくなります。
- Q1毎週のように変更が入っているか年に一度の診断と、実際の変更の速さの差がいちばん大きいのは、よく変わるプロダクトです。変更が多いほど、差分を取り込んで確かめ続ける意味が増します。
- Q2止まったり漏れたりすると、事業が困るか顧客のデータや決済、ログインを扱う、売上や信用に直結するプロダクト。そこで何を確かめ、何がまだかが分かることは、経営の判断材料としても重みを持ちます。
- Q3コードを社外に出せない事情があるか外部診断やクラウド型のAIレビューに渡せず、確かめる手段が止まっていたプロダクトほど、社内で完結することの差が大きく出ます。
- Q4起動方法が分かっているか開発者が普段使っている起動コマンドとURLを書き出せることが、始めるための条件です。
- Q5報告を受けて直せるチームがいるか再現手順つきの報告は、直す人がいてはじめて価値になります。修正が入れば同じ条件で試し直すので、直る流れまで見届けられます。
これは選ぶときの考え方で、どのプロダクトでどんな問題が見つかるかを約束するものではありません。