GitHub 初心者からマスターまで：包括的ガイド

GitHub で収益を得たいなら、最も直接的な方法は複雑ではありません。ライセンスが許す限り、価値のあるオープンソースプロジェクトを見つけ、デプロイ、日本語ドキュメント、アフターサービスをパッケージ化し、メルカリなどのプラットフォームで納品物として販売することです。

しかし、本当に収益を生むのは、情報のフィルタリングと実装能力です。AI に取り組みたい、FDE（フルスタック開発エンジニア）に転身したい、あるいは自身を OPC（ワンマンカンパニー）にしたいのであれば、コード、ドキュメント、バージョン管理、コラボレーションは、最終的に GitHub に集約されます。

たとえクリエイティブ活動や個人メディアをやっている場合でも、GitHub には大量のテーマ選定ツール、自動化プロジェクト、コンテンツ制作プロセスが存在します。ファイルが増え、AI が変更を加えるようになると、Git でバージョン管理をしなければ、すぐに状況は制御不能になります。したがって、プログラマーだけでなく、プロジェクトマネージャーやコンテンツクリエイターも学ぶ必要があります。それは、アイデアを管理可能で再利用可能、そして納品可能なプロジェクトに変えられるかどうかを左右するからです。

私はこの記事を仕上げるのに半月以上かけて、Git、GitHub、コミット、ブランチ、PR、そしてよくあるエラーを 0 から 1 まで練習しました。今後のライブ配信も、この同じプロセスに従います。本配信の前に、まずこのチュートリアルをオープンソースとして公開します。ブックマークしても、完全に手順を追っても構いません。

1. Git と GitHub：それぞれの役割

Git は、あなたのコンピュータにインストールするバージョン管理ツールです。オフラインでも、コミット、履歴の表示、ブランチの作成、マージが行えます。GitHub はリモートリポジトリとコラボレーションプラットフォームであり、Git がプッシュしたコミットを受け取り、Issues、Pull Requests、Actions、コードレビュー、権限管理を提供します。

Git で最も混乱しやすいのは、同じ変更が 4 つの異なる場所に存在し得ることです。以下の図は、ワークスペース、ステージングエリア、ローカルリポジトリ、リモートリポジトリの 4 つのレイヤーを分解したものです。

保存を押すと、コンテンツがハードドライブに書き込まれるだけです。git add は選択を担当し、git commit はローカルにバージョンを残し、git push はこれらのコミットを GitHub に送信します。

したがって、コミットする前に diff を確認し、実行またはテストを行います。プッシュが成功したら、Web ページに戻って再確認します。こうすることで、問題が発生した場合に、どのレイヤーで止まっているかをすぐに特定できます。

2. 始める前に：準備するものはたった 4 つ

必要なものは、Git、GitHub アカウント、エディタ、そして練習用プロジェクトです。エディタは VS Code で十分です。プロジェクトは Web ページでも Markdown ドキュメントでも構いません。

まず、ターミナルで Git を確認します。

1git --version

この演習では、macOS と Git 2.49.0 を使用します。Windows ユーザーは Git Bash または VS Code 内蔵ターミナルを使用できます。以下の Git コマンドは同じです。

次に、コミット作成者を設定します。

1git config --global user.name "Your Name"
2git config --global user.email "Your Email"

これはコミットレコードに書き込まれる作成者情報であり、GitHub へのログインには使用されません。現在の練習用プロジェクトのみに設定したい場合は、--global を --local に置き換えてください。

GitHub へのログインは別の問題です。コマンドラインでは、主に 3 つの方法が使用されます。

• GitHub CLI：gh auth login でブラウザ経由で認証。
• HTTPS：Personal Access Token または資格情報マネージャーを使用。
• SSH：公開鍵を GitHub に追加し、後で鍵を使って認証。

初心者は GitHub CLI または HTTPS を選ぶとよいでしょう。HTTPS を使用する場合、ターミナルが Password を尋ねてきたら、Token を入力します。通常のアカウントパスワードは使用できなくなりました。Token をコマンド、リモート URL、README、チャット、スクリーンショットに書き込まないでください。

3. 急いで init しない：ターミナルが実際にどこにあるか確認する

この演習は、シンプルな Web ページから始めます。ブラウザで開くことはできますが、まだ Git の履歴はありません。

プロジェクトには 3 つのファイルがあります。

1index.html
2style.css
3.gitignore

VS Code で「フォルダを開く」を選択し、単一の HTML ファイルをクリックしないでください。次に、内蔵ターミナルで以下を実行します。

1pwd
2ls

pwd は現在のディレクトリを表示し、ls はファイルを一覧表示します。index.html と style.css が表示されてから先に進みます。

この確認は馬鹿げているように見えますが、最も厄介なタイプの事故を防ぎます。つまり、誰かがデスクトップ、ドキュメント、あるいはユーザーのホームディレクトリで git init を実行し、その後 git add . で何千もの無関係なファイルをステージングエリアに入れてしまうことです。Git が壊れているのではなく、ディレクトリが間違っていたのです。

4. git init は何をするのか？

それでは、リポジトリを初期化します。

1git init -b main
2git status --short

git init -b main は、カレントフォルダに .git ディレクトリを作成し、初期ブランチに main という名前を付けます。.git は隠しディレクトリで、コミット、ブランチ、ステージングエリア、リモートアドレスなどの情報が保存されます。プロジェクトファイルはそのまま残り、Git はこの瞬間からそれらを監視し始めます。

スクリーンショットの ?? は、追跡されていないファイルを示します。ファイルは存在しますが、Git はまだそれらを記録するかどうかを決定していません。

リポジトリのルートディレクトリを確認するには、以下を実行します。

1git rev-parse --show-toplevel

出力は現在のプロジェクトフォルダになるはずです。fatal: not a git repository と表示された場合は、まずディレクトリを確認し、次に git init が実行されたかどうかを確認します。

5. 最初のコミット：信頼できる開始点を残す

プロジェクトはまだ変更されていませんが、なぜ最初にコミットするのでしょうか？それは、後続のすべての変更に比較可能な開始点が必要だからです。まず、ブラウザで Web ページを開き、タイトル、カード、登録エリアが表示されることを確認します。ウィンドウを狭めて、モバイル幅で横スクロールが発生しないか確認します。

次に、.gitignore を確認します。今回使用する内容は以下の通りです。

1.env
2.env.*
3*.log
4node_modules/
5dist/
6build/

.gitignore は、キー、ログ、依存関係、ビルド成果物をブロックするために使用されます。主にまだ追跡されていないファイルに対して機能します。キーがすでにコミットされ、後で .gitignore に追加した場合、その履歴は依然として存在します。真の処理には、キーの失効またはローテーションも含まれます。

最初のコミットのためにファイルを選択し始めます。

1git add index.html style.css .gitignore
2git status --short
3git diff --cached --stat

ステータスの A は Added（追加）を意味し、ファイルがステージングエリアに入ったことを示します。git diff --cached --stat は、コミットしようとしているファイルの数と、おおよその変更行数を教えてくれます。具体的な内容を確認するには、以下を実行します。

1git diff --cached

確認後、コミットします。

1git commit -m "chore: キャンパス AI 採用ページを初期化"
2git log --oneline
3git status

コミットは、作成者、時間、説明、親コミットを持つプロジェクトのスナップショットと考えることができます。ffdf4ff はこのコミットハッシュの短縮版であり、現在のリポジトリ内で使用すると、バージョンを正確に特定できます。

feat、fix、docs、style、chore は一般的なコミットタイプであり、必須の Git 構文ではありません。プレフィックスよりも重要なのは、その後に続く日本語（または英語）の説明です。何をしたか、どのオブジェクトを変更したか、なぜ変更したか。

6. 2 番目のコミット：AI による変更をレビュー用の下書きとして扱う

次に、ページに「登録方法を見る」ボタンを追加します。AI プログラミングツールを使用する場合、プロンプトに境界を記述します。

1index.html のみを変更し、紹介文の下に「登録方法を見る」リンクを追加してください。
2リンク先はページ内の #apply とします。style.css は変更しないでください。Git コミットは実行しないでください。
3完了したら、どのファイルを変更したか教えてください。

手動での変更も簡単です。

1<a class="cta" href="#apply">登録方法を見る</a>

AI が完了したと言っても、まだコミットしないでください。以下を実行します。

1git status --short
2git diff -- index.html
3git diff --check

git diff は、まだステージングされていないワークスペースの変更を表示します。緑の + は追加行、赤の - は削除行です。git diff --check は出力がないため、末尾のスペースなどの明らかなフォーマット問題は見つかりませんでした。ただし、ボタンがクリック可能かどうかはチェックしてくれません。

ブラウザに戻ってリフレッシュし、ボタンをクリックしてから、ウィンドウを狭めます。ページが登録エリアまでスクロールし、狭い画面でもボタンとカードが正常に表示されるはずです。

テストが成功した後にのみコミットします。

1git add index.html
2git diff --cached
3git commit -m "feat: 応募方法をすぐに確認できる登録エントリを追加"
4git log --oneline -2

これで、リポジトリには開始ページと登録ボタンという 2 つの明確なバージョンが存在します。後でボタンに問題が発生した場合、どのコミットで追加されたかを直接特定できます。

ちなみに、2 つの diff を区別します。

1git diff             # ワークスペースとステージングエリアの差分
2git diff --cached    # ステージングエリアと最新コミットの差分

git diff に出力がない場合、ファイルが保存されていないか、すでにステージングまたはコミットされている可能性があります。git status、git diff --cached、git log を順番に確認する方が、git add . を繰り返し入力するよりも信頼性が高くなります。

7. ブランチ：不確実な変更のためのテスト場所を残す

ボタンは 1 行追加するだけなので、リスクは小さいです。テーマ全体を紫からオレンジに変更するのは、見栄えが良くなるかもしれませんが、安っぽく見えるかもしれません。この種の変更はブランチに適しています。

1git switch -c experiment/warm-theme
2git branch --show-current

ブランチとは、概念的には特定のコミットを指す名前です。新しいブランチが最初に作成されるとき、それは main と同じコミットを指すため、ファイルはまったく同じです。実験用ブランチが新しいコミットを生成して初めて、2 つのラインは分岐します。

図では、青い main はまだ 2 番目のコミットを指していますが、オレンジの experiment はすでに 3 番目のコミットを指しています。プロジェクトは 2 セットのファイルを複製したわけではありません。2 つのブランチ名のポインタが変わっただけです。

style.css のカラー変数を変更し、ページをリフレッシュして確認した後、コミットします。

1git diff -- style.css
2git diff --check
3git add style.css
4git commit -m "style: 実験用ブランチで暖色テーマを試す"
5git log --oneline --graph --decorate --all

HEAD は現在自分がどこにいるかを示します。スクリーンショットでは、HEAD は experiment/warm-theme を指しており、main はボタンのコミットに留まっています。

暖色テーマを採用することに決め、main に戻ってマージします。

1git switch main
2git merge experiment/warm-theme

ここで Fast-forward が発生するのは、実験中に main に新しいコミットがなかったためです。Git は main ポインタを暖色テーマのコミットに直接進めます。変更は正常にマージされました。

マージされたブランチは安全に削除できます。

1git branch -d experiment/warm-theme

小文字の -d は、ブランチがマージされたかどうかをチェックします。大文字の -D は強制削除を行い、マージされていないブランチのコミットは参照を失う可能性があるため、日常的なクリーンアップコマンドとして使用しないでください。

8. コンフリクトは神秘的ではない。Git はあなたのために選択する勇気がないだけだ

コンフリクトを確認するために、リポジトリを複製しました。main はメインタイトルを「キャンパスの創造性をより多くの人に見てもらおう」に変更し、feature ブランチは同じ行を「アイデアを本当に使える作品に変える」に変更しました。マージ中に Git が停止しました。

コンフリクトマーカーは 3 つの部分に分かれています。

1<<<<<<< HEAD
2現在のブランチの内容
3=======
4マージしようとしているブランチの内容
5>>>>>>> feature/rewrite-heading

対処方法は、ファイルを編集し、最終的に残したいテキストを残し、3 組のマーカーを削除し、テストしてから、以下を実行します。

1git add index.html
2git commit

その時点で対処したくない場合は、マージを中断できます。

1git merge --abort

コンフリクトは、2 人の人間または 2 つのエージェントが同じ場所に対して異なる回答を出し、Git が自分で選択できないことを意味します。

9. ローカルリポジトリを GitHub に送信する

プロジェクトにはすでにローカル履歴があります。次に、GitHub でリポジトリを作成します。右上の + をクリックし、「New repository」を選択して、リポジトリ名を入力します。例：

1campus-ai-demo

最初の練習では、Private に設定することをお勧めします。ローカルにはすでに README、.gitignore、コミット履歴があるため、新しい GitHub リポジトリは空のままにします。Web 側で README、ライセンス、.gitignore を初期化しないでください。そうしないと、ローカルとリモートの両方に初期履歴が存在することになり、最初のプッシュで両者の関係を処理する必要が生じます。GitHub 公式の「Adding locally hosted code」もこれを明示的に注意しています。

HTTPS アドレスをコピーします。

1https://github.com/YourUsername/campus-ai-demo.git

プロジェクトのターミナルに戻ります。

1git remote add origin https://github.com/YourUsername/campus-ai-demo.git
2git remote -v
3git push -u origin main

origin はリモートアドレスのエイリアスです。他の名前でも機能しますが、コミュニティでは主要なリモートを origin と呼ぶ習慣があります。-u はローカルの main と origin/main の間に追跡関係を確立します。以降の操作は通常、git push を実行するだけですみます。

以下のターミナル図では、プッシュとクローンを実行するためにローカルのベアリポジトリを使用したため、既存の GitHub アカウントは変更されていません。GitHub に切り替える場合は、origin URL を置き換えるだけで、Git がコミットを渡し、追跡関係を確立するロジックは同じです。

実際のプッシュが完了したら、GitHub の Web ページに戻ってリフレッシュし、ファイル、README、デフォルトブランチ、コミット履歴がすべて表示されることを確認します。ターミナルの成功メッセージは 1 つの証拠であり、Web での確認は別の証拠です。

10. GitHub リポジトリを初めて読む：ページ上のこれらのものをどう読むか

以下は、GitHub 公式ドキュメントリポジトリの実際のページで、2026 年 8 月 15 日にスクリーンショットを撮影したものです。

リポジトリを開いたら、まず以下の場所を確認します。

• Code：ファイル、ディレクトリ、ブランチ、コミット。
• Issues：バグ、要件、タスク、議論。
• Pull requests：レビューまたはマージを待つ変更。
• Actions：自動テスト、ビルド、デプロイ。
• Security：セキュリティポリシーと脆弱性関連機能。
• Insights：コントリビューション、トラフィック、リポジトリのアクティビティ。
• README：プロジェクトの紹介と使用方法のエントリ。
• LICENSE：使用、変更、配布の許可方法。

馴染みのないプロジェクトを読むときは、最初に Stars を見つめないでください。まず 5 つの質問に答えてください。どのような問題を解決するのか、どうやって実行するのか、何に依存しているのか、最近メンテナンスされているか、ライセンスは何を許可しているか。Stars は注目度を反映します。セキュリティ、互換性、または権限をチェックしてくれるわけではありません。

11. clone、fetch、pull、push：4 つの方向を混同しない

初めてリモートリポジトリを自分のコンピュータに取得する場合：

1git clone https://github.com/OWNER/REPO.git

Clone は、ファイル、コミット履歴、リモート設定を取得し、通常は自動的にリモートに origin という名前を付けます。ZIP をダウンロードすると、その時点のファイルのスナップショットのみが取得され、完全な履歴はなく、リモート関係も確立されません。

その後によく使用される 3 つのアクションは以下の通りです。

1git fetch origin   # リモート情報をダウンロード、現在の作業ファイルは変更しない
2git pull           # fetch してから現在のブランチに統合
3git push           # ローカルコミットをリモートに送信

リモートで何が起こったかを最初に確認するには、以下を実行します。

1git fetch origin
2git status -sb
3git log --oneline HEAD..origin/main

ローカルに分岐がなく、Fast-forward 更新のみを受け入れたい場合：

1git pull --ff-only

pull は最初に fetch を実行し、次に設定に基づいて merge または rebase を実行します。チームは最初のコラボレーションの前に統合方法を合意し、分岐が発生した場合に問題を解決するために force push に依存しないでください。

12. 個人リポジトリから GitHub コラボレーションへ

Pull Request はマージ提案であり、コラボレーションが行われる場所です。議論、コードレビュー、自動チェックはすべて同じ一連の変更を中心に行われ、確認後に main にマージされます。

Issue が「イベント時間の説明を追加」であると仮定すると、ローカル操作は次のように行えます。

1git switch -c feat/event-time
2# ページを変更してテスト
3git add index.html
4git commit -m "feat: イベント時間の説明を追加"
5git push -u origin feat/event-time

プッシュ後、GitHub は通常、Pull Request の作成を促します。PR はマージ提案であり、説明、コミット、ファイル差分、コメント、レビュー、自動チェックを表示します。作成されたからといって自動的に main に入るわけではありません。

人がレビューしたくなる PR は、少なくとも 3 つのことを説明する必要があります。何を変更したか、なぜ変更したか、どのように検証するか。変更が集中すればするほど、レビューアーが問題を発見しやすくなります。

同じチーム内で、リポジトリへの書き込みアクセス権がある場合は、ブランチから直接 PR を送信できます。馴染みのないオープンソースプロジェクトに貢献する場合、一般的な方法は、まず自分のアカウントに Fork し、次に自分の Fork をクローンすることです。

1git clone https://github.com/YourUsername/ProjectName.git
2cd ProjectName
3git remote add upstream https://github.com/OriginalAuthor/ProjectName.git
4git remote -v

ここには通常、2 つのリモートがあります。

1origin    自分の Fork
2upstream  原作者のリポジトリ

元のプロジェクトを同期します。

1git fetch upstream
2git switch main
3git merge --ff-only upstream/main
4git push origin main

次に、新しいブランチで変更を完了し、自分の Fork にプッシュし、upstream に PR を送信します。Fork、clone、branch は 3 つの異なるものを解決します。Fork は GitHub 上のリポジトリスペースのセット、clone はリポジトリをローカルに持ってくること、branch はリポジトリ内の開発ラインです。

13. README と LICENSE が、他の人がそれを使用するかどうかを決定する

README は、少なくとも以下の質問に答える必要があります。

1. プロジェクトは何か。
2. どのような問題を解決するか。
3. インストールまたは実行方法。
4. 現在どの程度完成しているか。
5. 主要なファイルはどこにあるか。
6. 著者、素材、引用元は誰か。

コードは実行できても README が曖昧だと、3 ヶ月後には自分でも拾い上げられないかもしれません。最小限の README は見栄えが良い必要はありません。プロジェクト、実行方法、ステータスを明確に書くだけです。

公開リポジトリは、自動的にオープンソースライセンスを取得することを意味するわけでもありません。GitHub の公式ライセンス説明は明確に述べています。ライセンスがない場合、デフォルトの著作権ルールが依然として適用され、著者はコピー、配布、二次的著作物を作成する権利を保持します。公開とは、他の人がそれを見ることができ、GitHub の利用規約に従って Fork できることを意味します。コードを自分の公開または商用プロジェクトに取り込むには、リポジトリ内の LICENSE も確認する必要があります。

MIT、Apache-2.0、GPL などには、異なる義務があります。商用利用、再配布、または混合ライセンスに遭遇した場合は、完全なファイルを読み、必要に応じて専門家に相談してください。AI に「商用利用できますか？」とだけ尋ねないでください。

14. 間違えた後：変更がどのレイヤーにあるかを特定する

後悔薬は状態によって選ぶべきです。

間違ったファイルをステージングしたが、ファイルの内容は保持したい場合：

1git restore --staged filename

最新のコミットメッセージを間違えて書き、まだプッシュしていない場合：

1git commit --amend -m "新しいコミットメッセージ"

共有ブランチ上のコミットを取り消す必要がある場合：

1git revert commit_hash

revert は新しい逆のコミットを生成し、古い履歴は表示されたままになります。これは、すでにプッシュされ、複数の人が使用しているブランチに適しています。

git restore filename はコミットされていない変更を破棄します。git reset --hard はコミット、ステージングエリア、ワークスペースをすべて指定された位置に戻します。git push --force はリモートコミットを上書きする可能性があります。これら 3 種類の操作は、実行前にターゲットを確認し、バックアップを取ってから行う必要があります。ゼロベースの段階で一般的な修復ボタンとして扱わないでください。

15. 最もよくある 8 つのエラー：この順序で確認する

1. fatal: not a git repository

1pwd
2ls
3git status

通常、ディレクトリが間違っているか、現在のプロジェクトがまだ git init されていません。

2. Author identity unknown

1git config --local user.name "Your Name"
2git config --local user.email "Your Email"

3. nothing to commit

ファイルが保存されているか、別のコピーを変更していないか、変更がすでにコミットされているかを確認します。

1git status
2git log --oneline -3

4. remote origin already exists

1git remote -v
2git remote set-url origin CorrectGitHubAddress

5. src refspec main does not match any

リポジトリにまだコミットがないか、現在のブランチ名が main ではない可能性があります。

1git log --oneline
2git branch --show-current

6. Authentication failed or 403

リモート URL、リポジトリの所有権、アカウントの権限、認証方法を確認します。トラブルシューティングのために Token を他人に送信しないでください。

7. rejected non-fast-forward

リモートにはローカルにないコミットがあります。まず fetch して差分を確認します。いきなり force push しないでください。

1git fetch origin
2git status -sb
3git log --oneline --graph --decorate --all -10

8. Merge Conflict

git status を実行して UU ファイルを見つけ、最終的な内容を手動で決定し、テストしてから、add と commit を実行します。当面対処しない場合は、git merge --abort を実行します。

学生や同僚が「Git が壊れた」とだけ言ってきたら、以下の 5 つの出力を提出してもらいましょう：

1pwd
2git status
3git branch --show-current
4git log --oneline -5
5git remote -v

次に、オペレーティングシステム、実行したばかりの完全なコマンド、そして完全なエラーメッセージを追加します。ほとんどの問題は、ディレクトリ、ステータス、ID、リモートアドレス、または権限のいずれかのレイヤーにすぐに分類されます。

16. AI 時代において、Git は承認システムのようなもの

AI はあなたの代わりにコマンドを入力できますが、どの変更がビジネスの意図に合致するかを自動的に判断することはできません。プロンプトが 20 個のファイルを変更し、あなたが差分を確認せず、プロジェクトを実行せず、キーをチェックしなければ、Git はこの混乱を忠実に記録するだけです。

より安定した方法は、タスクを絞り込み、人間を承認の立場に置くことです。スコープ、差分、テスト、キーチェックのすべてが合格した後、人間がこれらの変更をコミットにできるかどうかを決定します。

AI に Git を操作させる際には、境界も設定しましょう：

1最初に git status と git diff を確認し、現在の変更のみを要約してください。
2コミットされていないコンテンツを破棄したり、reset --hard、clean、force push を実行したりしないでください。
3変更完了後に検証結果を提供し、自動的にコミットやプッシュを行わないでください。

コマンドを暗記できるかどうかは、もはやそれほど重要ではありません。重要なのは、ステータスを読み取り、AI が何を動かしたかを理解し、検証が十分かどうかを判断し、危険な操作が現れたときに停止を呼びかけられることです。

17. プロセス全体をもう一度実行する

1# 1. 場所を確認
2pwd
3ls
4
5# 2. 初期化
6git init -b main
7git status
8
9# 3. 最初のコミット
10git add index.html style.css .gitignore
11git diff --cached
12git commit -m "chore: Initialize project"
13
14# 4. 変更、確認、テスト、再度コミット
15git status --short
16git diff
17git diff --check
18git add index.html
19git commit -m "feat: Add registration entry"
20
21# 5. ブランチ実験
22git switch -c experiment/warm-theme
23git add style.css
24git commit -m "style: Experiment with warm theme"
25git switch main
26git merge experiment/warm-theme
27
28# 6. GitHub に接続
29git remote add origin https://github.com/YourUsername/RepoName.git
30git remote -v
31git push -u origin main
32
33# 7. 最終確認
34git status
35git log --oneline --graph --decorate --all
36git remote -v
37git diff --check
38git ls-files

各コマンドがどのレイヤーを変更したかを説明でき、間違ったディレクトリ、ステージングのエラー、マージコンフリクトを独立して処理できるようになれば、GitHub は単なるコードを保存するウェブサイトではなくなります。個人プロジェクトを、レビュー、監査、コラボレーションが可能なリポジトリに変えられるようになります。

次のステップでは、コマンドを収集し続ける必要はありません。実際の小さなプロジェクトを見つけて、7 日間連続で実行しましょう：毎日 1 つの小さな変更だけを完了し、差分を確認し、テストし、コミットし、GitHub にプッシュします。コミット履歴が、この一連の作業をあなたの習慣へとゆっくりと変えていきます。

私は Miles です。大企業から FDE に転身した AI アルゴリズムの専門家です。アルゴリズムの研究開発、最適化デプロイメント、企業研修を行ってきました。私をフォローしてください @miles_mazy 一緒に成長し、一緒に稼ぎましょう。