検査を始める前に ── 検査の全体像と、本番を壊さない線引き

上原正吉（EarthLink Network Co., Ltd.）。Claude Codeを開発の主体に据え、20を超えるプロダクトを1人で同時に開発・運用しています。これは、その現場の実測記です。

検査を始める前に ── 検査の全体像と、本番を壊さない線引き

この記事は、連載「自分のサービスは自分で守る ── AI 時代の自衛セキュリティ」の第 3 回です。自分でできる検査は自分で、難しいときは EarthLink Network が検査を代行し、直せない弱点は私たちが修正します。

連載の目次

1. AIで誰でも攻撃できる時代 ── やられる前に、自分のサイトを自分で検査する
2. 攻撃する側が持っているツール ── AI が自分で攻撃を進めるとは
3. 検査を始める前に ── 検査の全体像と、本番を壊さない線引き（この記事）
4. 外から攻めて検査する① ── 準備と、最初の実行まで（予定）
5. 外から攻めて検査する② ── 攻撃ツールと正規ツールで、見つかるものは違う（予定）
6. 自分の書いたコードを検査する ── 静的解析（予定）
7. 使っている部品の弱点を検査する ── 依存ライブラリ（予定）
8. インフラの設定の誤りを検査する（予定）
9. 検査の結果を 1 か所に集めて、どれから直すかを決める（予定）
10. 見つかった弱点の直し方 ── 3 つの道（予定）
11. 自分で直せないときは ── 保守契約という選択（予定）
12. 毎日自動で検査し続ける ── 作る時代から、守り続ける時代へ（予定）

結論

自分のサービスの検査は、1 種類では足りません。外から攻撃する側と同じように試す検査と、中身を調べる検査があり、中身を調べる検査はさらに、自分の書いたコード、使っている部品（ライブラリ）、サーバやクラウドの設定、の三つに分かれます。自分の書いたコードの検査には、鍵やパスワードの書き残しを探すことも含めます。それぞれ見つけるものが違うので、どれか一つだけでは見落としが出ます。出てきた結果を 1 か所に集め、毎日自動で回し、見つかったものを直す。ここまでがひとまわりです。

私たちは自社サービスの promptflow で、このうちコードと部品と秘密の置き忘れの検査を、毎日自動で回しています。使っているのは Trivy・Gitleaks・Semgrep という無料のツールで、2026 年 6 月 26 日から 10 月 23 日までに、決まった時刻の自動実行だけで 115 回実行されました。検査の中身そのものは、ほとんどが無料のツールで揃います。有料で変わるのは、コードを公開していない場合（GitHub などに非公開で置いている場合）に使えるかどうか、使える人数や回数の上限、結果をまとめて管理する画面などです。

そして、検査を始める前に決めておくことが四つあります。

1. 本番には向けない。コピーか、本番とは別の環境に向ける。
2. かけすぎない。範囲・回数・費用・時間に、機械で止まる上限をかける。
3. 使っているクラウドの、検査に関するルールを先に確かめる。
4. 自分のもの以外は調べない。

手を動かすのは次の第 4 回からなので、この回では検査の全体の様子と、守ることを先に揃えます。

検査の種類と、この連載のどの回で扱うか

検査には、大きく分けて二つのやり方があります。

一つは、動いているサービスに外から実際にリクエスト（サービスへの問い合わせの通信）を送って、弱点を探す検査です。攻撃する側と同じ目線で、入口を一つずつ試します。英語では動的な検査（DAST）と呼ばれます。

もう一つは、サービスを動かさずに、中身を調べる検査です。自分のサービスなら中身が手元にあるので、外からは見えない書き方の間違いや、古い部品まで見つかります。英語では静的な検査と呼ばれ、調べる相手によってさらに分かれます。

この連載で扱う検査を、種類ごとに並べます。ツールの名前は、私たちが実際に使ったものを例として添えています。

検査の種類	何を見つけるか	例として使うツール	扱う回
外から試す検査	動いているサービスの入口の弱点（応答の守りの設定の抜け、ログインの扱いの不備など）	ZAP（無料）、StackHawk（有料・お試しあり）、HexStrike（攻撃する側のツール）	第 4・5 回
自分の書いたコードを調べる検査	危ない書き方、鍵やパスワードの書き残し	Semgrep、Gitleaks（どちらも無料）、AI にコードを読ませる Strix	第 4・6 回
使っている部品の弱点の検査	知られた弱点が残っている古いライブラリ	Trivy（無料）、Dependabot（GitHub に無料で付いている）	第 7 回
インフラの設定の検査	サーバやクラウドの設定の抜け（公開しすぎ、鍵のかけ忘れなど）	Trivy の設定の検査、Checkov や Prowler（どれも無料）	第 8 回
結果を 1 か所に集める	重複をまとめ、重さで並べ、いつ直したかを残す	DefectDojo（無料）	第 9 回
直す・頼む	自分で直す、AI に直させる、直せる人に頼む	―	第 10・11 回
毎日自動で回し続ける	新しく見つかった弱点に、翌朝には気づく	GitHub Actions の定期実行	第 12 回

AI のツールは、この表の中で別の種類として立っているわけではありません。外から試す検査の段取りを AI にさせるもの（HexStrike）もあれば、コードを読む検査を AI にさせるもの（Strix）もあります。どちらのやり方の中にも「AI に段取りさせる型」がある、と考えるのが正確です。第 4 回でこの二つを実際に動かします。

なぜ、1 種類の検査では足りないのか

外から試す検査と、中を調べる検査は、見つけるものが違います。これは考え方の話ではなく、私たちが自分のサービスのコピーで実際に試した結果です。くわしくは第 5 回で並べますが、先に一つだけ言うと、同じログインまわりの処理を相手に、外から試すツールは「応答に付けるべき守りの設定（ヘッダ）が抜けている」ことを見つけ、コードを読むツールは「ログアウトしたのにサーバ側のログインが残る」「記録に書く『誰が』を、確かめていない鍵の中身から読んでいる」といった、外からは見えにくいものを見つけました。重なったものは、ほとんどありませんでした。

中を調べる検査にも、さらに種類があります。自分たちが書いたコードの危ない書き方、使っている部品の知られた弱点、そして鍵やパスワードの置き忘れ。サービスを動かしている土台（インフラ）の構成が手元にあるなら、その構成も同じように動かさずに調べられます。構成をファイルで管理していないサービスなら、いまの構成を設計図の形（Terraform など）に起こし直してから調べる、という手もあります。これは第 8 回で試します。

中を調べる検査には、もう一つ大きな利点があります。サービスを動かさないので、本番にも開発用の環境にも一切触れません。だから、検査に慣れていない人がまず始めるのに、いちばん安全です。

私たちが毎日自動で回している検査

ここからは実物です。promptflow のソースコードは、GitHub のリポジトリ（コードと変更の履歴をまとめて置いておく場所）に、外には公開しない形で置いてあります。そのリポジトリに、毎日 1 回、朝に自動で検査を回す設定が入っています。GitHub Actions という、GitHub に付いている自動実行の仕組みを使っています。

この設定で、毎日三つの検査が回ります。

• Trivy：使っている部品の一覧を見て、知られた弱点が残っているものを探します。弱点の一覧は毎日更新されるので、コードを何も変えていなくても、昨日まで無かった弱点が今日見つかることがあります。毎日回す理由はここにあります。
• Gitleaks：コードの中に、鍵やパスワードを書き残していないかを探します。
• Semgrep：自分たちが書いたコードに、危ない書き方がないかを、決まった型（ルール）に照らして探します。ここではセキュリティ向けの型の集まり（p/security-audit）を使っています。

三つとも、オープンソース（作り方の中身が公開されていて、誰でも無料で使えるソフト）の無料のツールです（Trivy は Apache-2.0、Gitleaks は MIT、Semgrep の本体は LGPL-2.1）。結果は第 9 回で見せる集約の置き場（DefectDojo）に送られ、新しく重い弱点（Critical か High）が見つかったときだけ、チャットに通知が届くようにしてあります。

では、本当に毎日回っているのか。GitHub の実行記録を、コマンドで取り出してみます。

直近の 10 回は、すべて成功です。記録をさかのぼると、最初の実行は 2026 年 6 月 26 日で、10 月 23 日までに決まった時刻の自動実行が 115 回あり、そのうち 114 回が成功、1 回が失敗でした（ほかに、人が手で 1 回起動しています）。1 回の実行は、多くが 1〜2 分で終わります。一覧の中に 1 時間 34 分かかった回がありますが、これも最後まで終わって成功しています。人が毎朝なにかをしているわけではありません。一度設定してしまえば、あとは機械が毎日回します。

部品の更新は、月に 1 回

使っている部品については、もう一つ別の仕組みも動かしています。GitHub に付いている Dependabot です。部品に新しい版が出ると、更新の依頼（プルリクエスト）を自動で作ってくれます。

ここは、正直に書いておきます。私たちの設定では、Dependabot は毎日ではなく、月に 1 回です。

4 種類の部品すべてが、月に 1 回の更新です。実際に Dependabot が作った更新の依頼を取り出すと（一覧の画面は第 7 回でお見せします）、おおむね月の初めにまとめて届いていました。

10 月 1 日には 69 個、9 月 1 日には 58 個の部品の更新が、それぞれ 1 本にまとめて届いています。8 月だけは、まとめた依頼が 1 日・4 日・7 日・11 日と 4 回作られました（前のものを閉じての作り直しが 3 回）。また、10 月 1 日と 9 月 1 日の 2 本は、取り込まずに閉じています。届いた更新をすべて取り込めているわけではない、ということも正直に書いておきます。取り込まずに閉じた理由は、第 10 回で、10 月 1 日の 1 本を例に書きます。毎日の弱点の検査は Trivy が、月に 1 回の新しい版への更新は Dependabot が受け持つ、という分担です。

Dependabot には、弱点が見つかった部品をすぐに知らせる機能（Dependabot alerts）もあり、これも無料です。弱点のある部品を見つけたときに自動で更新の依頼を作る機能（Dependabot security updates）もあります。私たちのリポジトリでは、この記事のために確かめるまで、どちらも有効にしていませんでした（2026-10-23 に GitHub の API（プログラムから問い合わせる窓口）に問い合わせて、どちらも無効の返事でした）。確かめたあと、同じ日の夜に、両方とも有効にしました。有効にしてからは、弱点のある部品が見つかると、月に 1 回の更新の日を待たずに、更新の依頼が届きます（有効にしたその夜にも、いくつか届きました）。毎日の Trivy の結果とどこが重なり、何が変わるかは、第 7 回で部品の検査を扱うときに確かめます。

無料でできること、有料で変わること

ここまでの検査は、すべて無料のツールで回っています。では、有料のツールやプランで何が変わるのか。各社の公式の料金ページを 2026 年 10 月 23 日に確かめて、撮っておきました。料金は変わるので、使う前にはご自分で最新のページを確かめてください。

まず、外から試す検査の ZAP です。ずっと無料のオープンソースです。

同じ外から試す検査でも、StackHawk には、ずっと無料で使えるプランはありません。

第 5 回で StackHawk を使った結果を見せますが、それはこの 14 日間の無料お試しの期間内で試したものです。続けて使うなら、1 人あたり月 10 ドルがかかります。

自分の書いたコードの検査では、GitHub の CodeQL が有名です。ただし、無料で使えるのは公開しているリポジトリだけです。

promptflow のリポジトリは非公開なので、CodeQL を使うには、コードを書き込む人 1 人あたり月 30 ドルの追加と、GitHub の Team 以上のプランが要ります。GitHub の API に問い合わせると、「Code Security を有効にしないとコードの検査は使えない」という返事でした。私たちは CodeQL を使っておらず、自分のコードの検査には無料の Semgrep を毎日回しています。

その Semgrep にも、無料の範囲と有料の範囲があります。

Semgrep には二つの無料の使い方があります。ログインせずにコマンドだけで使う版（Community Edition）と、Semgrep のサービスに登録して使う Free Edition です。私たちが毎日の検査で使っているのは前者です。Semgrep の公式の説明では、コマンドだけの版は一つの関数や一つのファイルの中しか調べず、ファイルをまたいだデータの流れは追いません。Free Edition に登録すると、10 人・10 個のリポジトリまでなら、ファイルをまたいで調べる機能も無料で使えます。

ほかのツールも合わせると、無料と有料の違いは、だいたい次の五つにまとまります。

1. 検査の中身は、多くが無料で揃う。 ZAP・Trivy・Gitleaks・Semgrep・Checkov・Prowler・DefectDojo は、どれもオープンソースで、検査そのものは無料で使えます。有料版がある製品で増えるのは、たとえば Prowler なら、予約して回す仕組み、まとめて管理する画面、チャットや課題管理のツールとの連携、サポートです（Prowler の公式の料金ページの説明）。
2. 公開リポジトリなら無料、非公開なら有料、という線引きがある。 GitHub の CodeQL と、鍵の漏れを止める機能がそうです。非公開のリポジトリで使うと、1 人あたり月 30 ドルと月 19 ドルがかかります。ただし Dependabot は、無料プランでも使えます。
3. 無料版は、量で区切られている。 Semgrep の Free Edition は 10 人・10 リポジトリまで、というように、人数・リポジトリの数・回数に上限があります。
4. 調べる深さで差を付ける製品がある。 Semgrep のコマンドだけの版のように、無料版は一つのファイルの中しか見ず、有料版や登録版はファイルをまたいで追う、というものです。
5. ずっと無料のプランが無い製品もある。 StackHawk は 14 日間のお試しだけです。「無料で使える」と書かれていても、お試しの期間のことなのか、ずっと無料なのかは、料金ページで確かめてください。

AI のツールについても書いておきます。第 4 回で使う Strix も HexStrike も、ツール本体は無料のオープンソースです（Strix は Apache-2.0、HexStrike は MIT）。かかるのは、中で動かす AI の利用料だけで、自分で選んだ AI の会社に払います。私たちが安い AI（DeepSeek）で動かしたときは、Strix で 1 回 0.45 ドル、HexStrike で 1 回 0.0331 ドルでした。

検査の対象は、本番ではなく「別の環境」に

ここからが、始める前の線引きです。いちばん大事なのは、検査を本番のサービスに向けないことです。

外から試す検査は、実際に攻撃と同じリクエストを送ります。本番に向けると、本番のデータを書き換えたり、お客さまに影響が出たりする恐れがあります。それに、公開中のサービスに強い検査を次々とかけると、通信を受けているクラウドの防御の仕組みが「これは攻撃だ」と判断して、送り元を遮断することがあります。自分で自分のサービスへの通信を止めてしまうわけです。ひどいときは、同じネットワークから出ている他のサービスまで巻き添えで遮断されます。守るための検査で自分のサービスを止めてしまっては、検査をする意味がありません。

だから、向ける先は二つのどちらかにします。

• 本番とは別に用意した、同じ作りの環境。 多くのサービスは、開発中の動作を確かめるための環境（開発環境、dev 環境）を持っています。そこへ向ければ、本番のお客さまにもデータにも影響しません。
• ソースコードのコピー。 中を調べる検査なら、コピーを動かす必要すらありません。

ここで、私たち自身が思い違いをしかけたことを書いておきます。「手元のパソコンで起動したサービスなら、本番とは別だから安全だろう」と思いがちですが、そうとは限りません。

promptflow のコードは、データベースの表やファイルの置き場の名前を指定しないで起動すると、すべて本番の名前を使います。手元で起動するための .env.local には、本番の鍵がそのまま入っています。開発用の環境（staging）の値を入れて起動すれば、多くの表は開発用のものに向きます。それでも、ファイルの置き場は、その開発用の環境でも本番と同じものを使っています（どれも 2026-10-24 に、いまのコードと、コードに残した設定の注記で確かめました）。起動のしかたによっては、手元のサービスに外から検査をかけると、検査のリクエストがそのまま本番のデータを読み書きします。「手元だから安全」とは限らなかったのです。検査を始める前に、自分のサービスが手元や開発環境でどこにつながっているのかを、設定ファイルで確かめてください。

そこで私たちは、二つのやり方を選びました。一つは、ソースコードのコピーを作って、コードを読む検査だけをすること（第 4 回の Strix）。もう一つは、外から試す検査のために、ログインまわりの処理だけを写したコピーを、外から入れない閉じた環境で動かすことです（第 4・5 回の HexStrike・ZAP・StackHawk）。

この閉じた環境では、検査される側（target）は外に入口を持たず、同じ仮のネットワークの中にいる攻撃役からしか届きません。外から入ることはできませんが、中から外へ出ていく通信までは止めていません。攻撃役も AI を呼ぶために外へ通信しますが、検査のリクエストを送ってよい先は target だけです。本番のデータベースにも、本物のログインの仕組みにもつながっていません。

ただし、この環境は、本番と同じ作りの開発環境そのものではありません。ログインの相手を簡易版で置き換えているので、その簡易版の甘さが、弱点のように見えてしまうことがありました。これは第 5 回でそのまま見せます。本番と同じ作りの環境で外から試すことは、まだやっていません。

開発用の環境がない小さなサービスでも、心配は要りません。ソースコードのコピーを中から調べるだけなら、動かす必要がないので、本番にも開発環境にも一切触れません。まずはそこから始めれば十分です。

攻撃をかけすぎないための線引き

二つ目の線引きは、量です。検査の相手がコピーでも、範囲・回数・費用・時間に上限をかけておきます。上限は人が気をつけるのではなく、機械が止めるようにします。人は途中で目を離すからです。

私たちが外から試す検査で使った、攻撃する側のツールを動かすスクリプト（ツールに手順を渡して動かす小さなプログラム）には、次の三つを入れました。

• 向かってよい相手を一つに決める。 AI がほかの宛先を検査しようとしても、スクリプトが断ります。AI は指示を取り違えることがあるので、「相手はここだけ」とお願いするだけでなく、機械で止めます。
• 費用の上限を決める。 上限は 2 ドルにしました。実際に使ったのは 0.0331 ドルでした。
• 手数の上限を決める。 AI が考えて次の手を決める回数を、24 回までにしました。

ほかのツールでも同じです。第 4 回の Strix は、コマンドで費用の上限を 1 ドルにして実行し、実際には 0.45 ドルで止まりました。第 4・5 回で使う StackHawk は、設定ファイルで、サイトの中をたどる時間を 5 分まで、検査の時間を 15 分までにしました。範囲を絞ることも、量の上限の一つです。promptflow には外から触れる入口が 231 本ありますが、最初の検査は、そのうちログインまわりの 4 本に絞りました。

クラウドの「検査のルール」を先に確かめる

三つ目の線引きは、クラウドの事業者のルールです。開発用の環境でも、それがクラウドの上にあるなら、検査の通信はクラウドの事業者の設備を通ります。大きなクラウドの事業者は、利用者が自分のサービスに検査をかけてよい範囲を、あらかじめ決めて公開しています。

AWS のルールのページを見てみます。

一覧にあるサービスなら、事前の承認なしに検査できます。ただし、大量のリクエストでサービスを止めるような検査は、自分のサービスに対してでも禁止です。ログインの入口に何千回も送りつけるような検査は、ここに当たります。量に上限をかける理由は、自分のサービスを守るためだけではなく、クラウドのルールを守るためでもあります。

もう一つ、一覧そのものを確かめることも大事です。promptflow は AWS の Amplify というサービスで配信していますが、2026 年 10 月 23 日の時点で、Amplify はこの一覧に名前がありません。一覧にないサービスを検査したいときは、AWS のサポートに相談するように、と書かれています。つまり、私たちが公開中の環境に外から検査をかけるなら、その前に AWS に相談する必要があります。今回、閉じた環境とコードのコピーで検査したのは、この点でも安全でした。

ほかの大手のクラウドの窓口も挙げておきます。手続きは事業者ごとに違います。

• AWS：許可された主なサービスへの検査は、事前の申請なしに行えます。大量の通信で止めるような検査は禁止で、その模擬をしたいときは専用の手続きが要ります（AWS の検査のルール）。
• Google Cloud（GCP）：自分のプロジェクトへの検査は、Google への事前の連絡は不要です。ただし、利用規約（Acceptable Use Policy）を守り、ほかの利用者に影響を与えない範囲で行います（GCP のセキュリティに関する FAQ）。
• Microsoft Azure：事前の承認も通知も不要です。ただし、事業者が定める「検査の実施ルール（Rules of Engagement）」に従う必要があります（Azure の検査のルール）。

これら以外のクラウドやレンタルサーバを使っている場合は、契約している事業者に「自分のサービスにセキュリティの検査をかけてよいか、事前の連絡や申請が要るか」を必ず確かめてください。黙って強い検査をかけると、遮断されるだけでなく、規約に反する行為として扱われることがあります。

自分のもの以外は、調べない

四つ目の線引きは、第 1 回でも書いたことです。検査していいのは、自分のものだけです。他人のサイトや、自分が権利を持っていないシステムに検査をかけるのは、法律に触れます。

気をつけたいのは、自分のサービスが「つないでいる先」です。決済、メールの配信、ログインの仕組みなど、多くのサービスは外の会社の仕組みにつながっています。自分のサービスから呼んでいるからといって、その先は自分のものではありません。外から試すツールを動かすときは、検査のリクエストが、つないでいる先の会社のサーバにまで飛ばないように、向かってよい相手を一つに決めておきます。さきほどのスクリプトで、相手以外のホストを断るようにしたのは、このためでもあります。

では、つないでいる先の危なさは、どう確かめるのか。相手のサイトを検査するのではなく、自分が使っている部品の一覧と、公開されている弱点の情報を突き合わせます。それが第 7 回の部品の検査と、第 9 回の結果の集め方の話です。

どこで区切るか（費用の話）

最後に、範囲と費用の決め方です。入口が 231 本もあるサービスを、全部まとめて一つずつ深く調べようとすれば、費用も時間もかかります。選べる道は三つあります。

• 費用のかからない、中を調べる検査を、まず隅々まで。 Trivy・Gitleaks・Semgrep のような AI を使わない検査は、費用がかからないので、コード全体を毎日調べられます。私たちが毎日回している検査は、これです。
• 範囲を絞って、一か所ずつ深く調べる。 入口を用途ごとに区切り、一つのまとまりずつ AI に深く調べさせれば、少ない費用でも深いところまで届きます。ログインまわりの 4 本に絞った Strix の検査は、0.45 ドルでした。
• 費用をかけて、深いところまで一度に調べる。 入口が多いサービスを丸ごと深く調べるなら、その分の費用をかけます。

小さなチームなら、一つ目から始めて、二つ目へ進むのが現実的だと思います。一度に完璧を目指さず、まず無料の検査で全体を見て、気になるところから順に AI で深く調べる。1 つのまとまりを深く調べた費用は、私たちの場合 0.45 ドルでした。情報が漏れて、お客さまへのおわびやサービスの停止に追い込まれることを思えば、検査にかける費用は、保険として安いほうだと私は思います。むしろ、検査にいくらかけるかを、はっきり予算として決めておくこと自体が、これからの運営には欠かせません。

始める前に確かめること

ここまでを、始める前の確認の一覧にまとめます。第 4 回から先は、この一覧を満たした状態で進めます。

1. 自分のサービスが、手元や開発環境で、どこのデータベースや保存先につながっているかを、設定ファイルで確かめた。
2. 検査の相手を、本番とは別の環境か、ソースコードのコピーに決めた。
3. 外から試すツールが向かってよい相手を一つに決め、それ以外を機械で断るようにした。
4. 費用・回数・時間の上限を、ツールの設定かコマンドで決めた。
5. 使っているクラウドの検査のルールを読み、自分の使っているサービスが一覧にあるかを確かめた。
6. 検査の相手に、自分のもの以外（つないでいる先の会社のサーバなど）が入っていないことを確かめた。

次回

次回の第 4 回から、手を動かします。外から攻めて検査する、の一回目です。攻撃する側と同じクラスの AI の検査ツールを、自分のサービスのコピーに使います。ツールを入れるところから、安い AI につなぎ、費用の上限をつけて実行し、最初の結果が出るところまでを、入力した内容と画面を一つずつ並べて見せます。

---

この連載では、攻撃ツールが誰でも無料で手に入る時代に、自分のサービスを自分で検査し、弱いところを先に見つけて直す手順を、順に示します。検査の対象は自社サービスに限り、他人のサイトを攻撃する手順は扱いません。 自分で検査するのが難しい方は、EarthLink Network が検査を代行します。弱点は見つかったが自分では直せない、という方は、私たちが修正まで引き受けます。お気軽にご相談ください。 役に立ったと感じたら、ぜひ「いいね」と記事の購読をお願いいたします。

自社プロダクトは https://www.eln.ne.jp/products にまとめています。

筆者について

上原正吉。EarthLink Network Co., Ltd. でAI開発をしています。2025年からClaude Codeを開発の主体に据え、今は20を超えるプロダクトを1人で同時に開発・運用しています。この連載では、その現場で実際に起きたこと（うまくいったことも、失敗も）を、数字と一緒に書いていきます。

また、AIで業務や開発を組み替えたい会社・チーム向けに、AI活用のコンサルティングも受け付けています。ご相談は www.eln.ne.jp からどうぞ。

---

EarthLink Network は、会社の全業務を AI で回すために、必要になったものを自社で作っています。いま作っているプロダクトの一覧と概要は、こちらにまとめています。

→ EarthLink Network が自社でつくっている18のプロダクト

会社と各プロダクトの詳細は、公式サイト www.eln.ne.jp をご覧ください。