GitLab をすぐに使い始められるよう、推奨される次の手順をリストにしました。
すでにプロですか？この README.md を編集して自分好みに変更しましょう。簡単にしたいですか？下部のテンプレートを使用してください！
cd existing_repo
git remote add origin https://gitlab.com/guardia-ai/gitlab-component.git
git branch -M main
git push -uf origin main
GitLab に組み込まれた継続的インテグレーションを使用します。
この README を自分好みにする準備ができたら、このファイルを編集して便利な以下のテンプレートを使用してください（または自由に構成してください - これは単なる出発点です！）。このテンプレートについては makeareadme.com に感謝します。
プロジェクトはそれぞれ異なるため、これらのセクションのうちどれがあなたのプロジェクトに該当するかを検討してください。テンプレートで使用されているセクションは、ほとんどのオープンソースプロジェクト向けの提案です。また、README が長すぎて詳細すぎる場合でも、短すぎるよりは長すぎる方が良いことを覚えておいてください。README が長すぎると思われる場合は、情報を削るのではなく、別の形式のドキュメントを利用することを検討してください。
プロジェクトには自己説明的な名前を選んでください。
あなたのプロジェクトが具体的に何ができるかを伝えましょう。コンテキストを提供し、訪問者がなじみのない可能性のある参照へのリンクを追加します。ここには、機能のリストや背景のサブセクションも追加できます。プロジェクトに代替手段がある場合は、差異を示す要素をリストアップするのに適した場所です。
一部の README では、プロジェクトのすべてのテストが合格しているかどうかなどのメタデータを伝える小さな画像を見ることができます。Shields を使用して README にバッジを追加できます。多くのサービスにはバッジ追加の手順もあります。
何を作成しているかにもよりますが、スクリーンショットやビデオを含めることは良いアイデアです（実際のビデオよりも GIF がよく見られます）。ttygif のようなツールが役立ちますが、より高度な方法については Asciinema をチェックしてください。
特定のエコシステム内では、Yarn、NuGet、Homebrew などの一般的なインストール方法があるかもしれません。ただし、あなたの README を読んでいる人が初心者であり、より多くのガイダンスを必要としている可能性も考慮してください。具体的な手順をリストアップすることで曖昧さを排除し、人々ができるだけ早くあなたのプロジェクトを使い始められるようにします。特定のプログラミング言語バージョンやオペレーティングシステムなど、特定のコンテキストでのみ実行される場合、または手動でインストールする必要がある依存関係がある場合は、要件のサブセクションも追加してください。
例を自由に使用し、可能であれば期待される出力を示してください。インラインで実演できる最も小さな使用例を用意し、より洗練された例が長すぎて README に含めるのが合理的でない場合は、それらのリンクを提供すると役立ちます。
人々がどこに助けを求めに行けばよいかを伝えてください。Issues トラッカー、チャットルーム、メールアドレスなどの任意の組み合わせが可能です。
将来のリリースに関するアイデアがあれば、README にリストアップすることをお勧めします。
貢献を受け入れているかどうか、およびそれを受け入れるための要件を明記してください。
プロジェクトに変更を加えたい人にとって、開始方法に関するドキュメントがあると便利です。おそらく、実行すべきスクリプトや設定すべき環境変数があるかもしれません。これらの手順を明確にしてください。これらの指示は将来の自分自身にも役立つ可能性があります。
コードを lint したりテストを実行したりするコマンドを文書化することもできます。これらの手順は、高いコード品質を確保し、変更が誤って何かを壊してしまう可能性を減らすのに役立ちます。テストの実行手順は、ブラウザでのテスト用に Selenium サーバーを起動するなどの外部セットアップが必要な場合に特に役立ちます。
プロジェクトに貢献してくれた人々への感謝の気持ちを示しましょう。
オープンソースプロジェクトの場合は、ライセンスがどのように適用されるかを記載してください。
プロジェクトに費やすエネルギーや時間がなくなった場合、README の上部に開発が遅くなった、または完全に停止したことを示すメモを追加してください。誰かがあなたのプロジェクトをフォークしたり、メンテナーや所有者として手を挙げてプロジェクトを継続させたりするかもしれません。また、メンテナーを明示的に募集することもできます。
どの AI ライブラリを使用しているかを検出するだけでなく、スキャナーはソースを読み取り、特定の行で具体的な義務を報告します：
| ルール | 内容 |
|---|---|
GA-ART50-001 | モデルに到達するユーザー向けエンドポイントがあり、リポジトリ内のどこにも応答が AI によって生成されたという開示がない場合 |
GA-ART12-001 | スコープ内にログ、監査、またはトレース呼び出しがない状態でモデルが呼び出された場合 |
検出結果は3つの方法で表示されます：マージリクエストへのコメント、コード品質レポートによるマージリクエストの差分へのマーカー、そして API キーを使用して Guardia ダッシュボードへのレコード（コミットごとに修正した内容と導入した内容を追跡するもの）として表示されます。
include:
- component: gitlab.com/guardia-ai/gitlab-component/scan@main
inputs:
guardia_api_key: $GUARDIA_API_KEY # optional — keeps the record
code_analysis: 'true'
fail_on_findings: 'none'
検出結果は自動的に解決されます。コードを修正（当社のパッチまたはご自身のもの）すると、次のスキャンでは単に報告されなくなります。クリックする必要はありません。
代わりに受け入れる場合は、コード内で次のように明示してください：
# guardia: ignore GA-ART50-001 — notice is rendered by the chat UI shell
これによりビルドが失敗することはなく、git blame による作者情報とともに文書化されたリスク受領としてダッシュボードに記録されます。これは監査人が確認したい情報です。
5年前のリポジトリには、現在のチームメンバーが原因ではない検出結果が含まれている可能性があります。一度それらを凍結し、新しい作業のみがクリーンである必要があります：
guardia-scan . --write-baseline .guardia/baseline.json
そのファイルをコミットします。ベースライン化された検出結果はレポートとダッシュボードに表示されたままになりますが、チェックを失敗させることはありません。その後導入されたものは失敗します。
実行ごとに、改ざん防止可能なレコード（何が、どのコミットで、どのルールパックのバージョンで見つかったか、および各ルールが当時どの程度の法的レビューを受けていたか）を書き込むことができます：
- uses: GharbiiAhmed/guardia-ai-action@v1
with:
evidence-file: guardia-evidence.json
evidence-signing-key: ${{ secrets.GUARDIA_EVIDENCE_KEY }} # optional
レコードはハッシュで連鎖するため、過去のものを変更するとその後のすべてのレコードが壊れます。署名鍵がない場合は内部的な一貫性を示すだけで、真正性は証明しません。レコード自体がそれを明示しており、あなたが推測する必要はありません。
検出結果はコードの動作を記述し、義務を引用します。違反していると断言することはありません。義務が適用されるかどうかは、システムの目的とデプロイメントコンテキストに依存し、コードスキャンでは判断できません。ルールは Regulation (EU) 2024/1689 をそのまま引用しているため、あなた自身で推論を確認できます。
検出は完全にオフラインで実行されます。ソースコードがランナーの外に出ることはありません。